This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The BPEL debugger is hard to find, so much so that there is almost no indication in the product that there is a BPEL debugger at all. It is difficult to find for a couple of reasons: - The composite application doesn't follow regular NetBeans conventions. Convention would have a "Debug Project" action on the project menu that would build and deploy the project and enable the debugger all at once - The Attach Debugger... feature is a low-traffic manual feature and it is not readily apparent from the attach dialog that the user can choose an alternative debugger. Users will not know they need to attach to the BPEL debugger manually first in order to do any sort of debugging. Furthermore, enabling debugging on the BPEL runtime is not as easy as it could be, by comparison with the Application Server, which has a Run in Debug Mode action that does everything in one step. Suggested solutions: - Include a Run in Debug Mode action on the BPEL service engine runtime tab that restarts the engine in debug mode in one step - Add Debug Project action after the Test Project action on the composite application project context menu. The behavior of this action should be the following: ensure runtime is in debug mode, and if not, restart it in debug mode (or notifies the user); builds project; deploys project. This should generally be consistent with the behavior of Java EE applications.
Let me only add that the action BPEL service engine in the runtime tab should be "Start in Debug Mode" rather than "Run in Debug Mode".
I think this should be broken into different bugs or RFEs. The ""Start in Debug Mode" action on BPEL service engine should be a JBI Manager bug. The "Debug Project" action on Comp App should be a compapp project bug.
Good point, so you can split this bug and make it an umbrella of the other two.
This is now a sub-issue of issue 83731, which covers debugging support for all JBI module projects. For the BPEL "Debug Project" action, the following steps should be done when the action is trigged (including comments from Mike Frisino): 1. ensure runtime is in debug mode, and if not, restart it in debug mode. Worst case, if not possible, it would have to at least inform user that server is not in debug mode and they need to go to runtime tab blah blah (see other rfe).. But hopefully, it can be done for them from here. 2. builds project 3. deploys project 4. obtains the attach-to port number from the bpelse 5. attaches the bpel debugger to localhost:<portNumber> (without bringing up the attachment dialog). Have to consider contingency of port mismatch and provide user with "error: could not attach automatically, please use the explicity Run > Attach Debug" type message. One option is to have "Debug Project" invoke a test run of a "designated default test case". So, the test cases could have a "Set as Default" action on them and the "Debug Main Project would invoke the current default. This is a convenience and not necessarily part of the action plan. From Jun Qian: Since you know your server instance for your BPEL Project, you can get the actual server address and port from NetBeans’ server config file (${userdir}/config/J2EE/InstalledServers/.nbattrs). From there, you make a MBeanServerConnection, and so on. From Todd Fast: Being able to toggle debug mode on or off at runtime without restarting solves half the problem, so it's good to know about that option... if this is done, then there is no value at all to the (BPEL SE) "Start in Debug Mode" action.
I believe Josh's comment is perfectly accurate. And thorough. As for it, I would rename the original Summary from "BPEL debugging is hard to find and difficult to enable" to smth like "Debug Project support for BPEL Projects" and add a dependecy on issue 83731. Also, I think this issue doesn't really apply to the BPEL Debugger itself, but to the BPEL Project. Reassigning then, please evaluate.
Some technical notice. To start a BPEL Debugger Session from your module you need to use an API defined in BPEL Debugger API module. The code would be quite simple: DebuggerManager.getDebuggerManager().startDebugging( DebuggerInfo.create(AttachingCookie.ID, new Object[] { AttachingCookie.create(host, port) }));
retitled this bug becuase prior title was too general.
Initial test case debugging support has been added. Note that the new Debug Test Case Action is similar to the existing Run Test Case action in that it doesn’t build or deploy project. The project has to be deployed first. Things to do: * add remote debugging support; * ignore test case timeout property during the debug session; * restore (BPEL) SE debug property after the debug session. Currently, the new debug action is added on the test case node. I am not sure about the "Debug Project" action on the CompApp project node. Yes, we can have a "Set Default Test Case" action, ant let the "Debug Project" action on the project node run the default test case, but it will be inconsistent with the existing "Run Project" action, which runs all the test cases in the project. Anyone?
Jun, what does "remote debugging support" mean? Can't we debug BPEL processes deployed on the remote appserver, can we?
According to Mei, we do have remote BPEL process debugging support.
My understanding form earlier discussions was to add a "debug" menu item in all project context menu in addition to the global debug button. Basically we are placing the same sign in multiple places so that the user can find it easier. The proposed implementation was that the bpel project will associate its project debug action with an ant target. The compapp project will use the same ant target to invoke bpel debug action if the user like to click on the compapp project one. The compapp project does not needed to add dependency on the various debugger modules for doing this.
From my understanding, starting BPEL debugger from CompAppProject by invoking an ant task of BpelProject is one of the possible approaches. Another approach could be that CompAppProject declares some SPI which component projects (such as BpelProject) would implement. Both approaches would eliminate the cross-references between compapp and bpel suites.
Created a wiki page for this issue's discussion - see issue's URL (http://xdesign-tools.czech.sun.com:8080/JSPWiki/Wiki.jsp?page=IZ83255).
re-assigning to Alexander Z.
After elaborating on this issue and the related issue 83731 I've realized that we need to revise our approach in the following aspects. We have three parties involved in the "Debug Project" workflow. These are: - Composite Application Project - JBI Module Projects (such as BPEL Project) - Service Engine's Debugger Engine (such as BPEL Debugger Engine). First, we wanted CompApp project's "debug" target to delegate it to its subprojects' "debug" ant targets (after doing some preparation which includes deployemnt of the CompApp project). Each subproject was supposed to start its own Debug Session which would lead to as many debug sessions as the number of CompApp's subprojects. This approach would also require JBI Module Projects to be dependent on the Debugger Engines. I would like to propose another approach which utilizes the NB Debugging Framework in more extent, particularly, which allows us to have only one Debug Session and have various Debugger Engines registered for it. It is similar to what we can see when debugging some j2ee ear application using NB. In EarApp debugging there is only one Debug Session with two Debugger Engines registered - JSP and Java. When Java breakpoint is reached the Java Debug Engine becomes current, and for JSP breakpoint it would be the JSP Debug Engine. User can see/change the current Debug Engine in the Sessions View - column "Language", but normally he/she doesn't need to go there since NB Debugging Framework does the necessary context switches automatically. So, in the proposed approach, CompApp's "debug" ant target creates a single Debug Session, which doesn't know anything about its subprojects or Service Engines or Debugger Engines. It serves as the context for the various Debugger Engines and provides a lookup to get Session related information like CompApp's base dir and the J2ee Server Instance being used. Debugger Engines may subscribe themselves to the CompApp Debug Session and use its lookup to setup themselves. With this approach we end up with: - CompApp knows only about NB Debugger APIs (doesn't have to know about subproject types or Debugger Engines) - JBI Module Projects doesn't know anything about debugging or CompApp - Debugger Engines know the string ID of the CompApp Debug Session as well as the string keys for the properties in the Sessions's lookup. They might know about JBI Module Projects but they don't have to.
The BPEL Debugger engine has been modified to support the approach described in the previous comment. Particularly, now it would include itself in Debugger Sessions with the type key of "CompAppDebuggerSession". It would expect that the Session's lookup has the Map object that contains the following entries: - "projectBaseDir" maps to CompApp project's base dir (string) - "j2eeServerInstance" maps to an ID of the registered server instance assigned for the CompApp (string) - "com.sun.bpelse-1.0-2" maps to another map, which holds the BPELSE specific information (java.util.Map). The only entry in this map is "port" which maps to an Integer value of BPELSE's "DebugPort" property. The "com.sun.bpelse-1.0-2" map entry is somewhat temporary solution. I believe that in the future BPEL Debugger Engine should get all the required BPELSE's properties by itself, as suggested by Jun Qian: "From Jun Qian: Since you know your server instance for your BPEL Project, you can get the actual server address and port from NetBeans’ server config file (${userdir}/config/J2EE/InstalledServers/.nbattrs). From there, you make a MBeanServerConnection, and so on."
The BPEL part of this issue is closed (see the previous comment), but it needs that issue 83731 to be closed as well to make the "Debug Project" story complete. Without fixing issue 83731 the fixes for this issue doesn't make any sense since they don't add any value from the user perspecitve (specifically, don't add a "Debug Project" menu item).
The blocking issue 83731 has been fixed (at least, in its BPEL part). So, now you can debug your BPEL project by invoking its CompApp context menu action "Debug Project (BPEL)" or by using Main menu or main toolbar. Closing this issue.
*** Issue 81898 has been marked as a duplicate of this issue. ***
There is Debug Project (BPEL) menu item on Comp App verified on 070313 for WinXP