Posts tagged Debugging
JDeveloper – Conditional Breakpoints saving time and a lot of clicking (IDE tip)
0One of the biggest time-savers in in ADF 11g (R1) development, is working on the application while it is running on the WLS server in debug mode. In this mode, I can analyze the execution of my code, inspect variables and make many code changes that are applied ‘on the fly’. I can then analyze the execution of the modified code and so on.
Recently I was debugging a piece of Java code that was executed as part of a Web application. I had started the (ADF) web application on WebLogic Server in Debug mode and using JDeveloper for remote debugging. I had inserted several breakpoints in the code. Whenever the thread would hit the breakpoint, execution would be paused and control was handed to me to inspect and potentially manipulate variables, analyze the callstack and step-by-step investigate code execution. Wonderful!
Unfortunately however, the breakpoint was in a section that was invoked quite frequently, probably because it was somehow located inside a loop. I was interested only in inspecting a very specific situation – only two out of more than one hundred breakpoint occurrences. After clicking my way through dozens of irrelevant breakpoint instances – and just missing the one More >
Do not register bugs, Fix them!
5For years I was a proponent of bug/issue management systems and worked with open systems like Jira or Bugzilla and also with a lot of proprietary systems. I’ve used these systems during the development and production/ support phase of the products. Every time I use these systems I spend too much time registering, evaluating and sorting issues. At the end of the project I always get stuck with a dozen of unspecified issues with a vague status. Why is this? Bug tracking systems are not bad. The entire process of registering and tracking bugs is wrong.
What the most effective thing to do when you discover a bug? Registered the bug in a system and track it? Does this solve the bug? It doesn’t.  You should be busy resolving the bug, not administrating and tacking it!
ADF 11g: Debugging Task Flows embedded from ADF Libraries using source code jars
1We have been struggling quite a bit with a good approach for modularizing our ADF web applications through the use of (stand alone) Task Flows that are developed in independent projects and assembled into a single Web Application from ADF Libraries. In theory, this is a very structured, decoupled way of developing potentially complex ADF Web Applications – while allowing for reuse. The contextual events mechanism in combination with the task flow input parameters allow definition of a clear interface through which to reuse the task flow. So all seems well.
However, when you try to put this theoretical bliss into actual practice, there are some limitations that you run into. One of the tricky issues we had to deal with is: how can we debug our web application when part of the source of the application is reused from ADF Libraries? How can we put breakpoints in the sources that are part of the ADF Library?
On closer inspection, there seems to be a relatively easy way for doing this – using an additional library definition in JDeveloper that refers to the sources that form the foundation of the ADF Library.
Let’s take a quick look at how this would work:
Debug Logging in BPEL using Sensors – Part 1
When developing and/or debugging BPEL processes, the Oracle BPEL Console is your best friend. Every change to every variable, every activity that was executed, everything is right there for you to inspect, whether the instance is still in-flight or already completed. But although this sounds like the ultimate debugging tool, I’m sure you’ve noticed like me that when your processes get really big (which they tend to do rather quickly), there’s two reasons why debugging can be difficult. The first is plain and simple “information overloadâ€. If your audit flow contains hundreds of activities and possibly thousands of variable data changes, finding an individual piece of information is not trivial. I find the second reason, however, to be of even more profound impact: the BPEL console will not show you the execution path through your process flow (which would indicate which parts of the code got executed, and which didn’t), but rather it displays a long, sequential list of Activities that were executed. Especially if you have a lot of switch and/or pick statements, and if your code contains loops (in which case each iteration will add all executed Activities to the list), More >
Recent Comments