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.
Original status: 1-Dispatched; Suggested Status: NEW Original Target Release: coke_dev; Suggested Target Milestone : 5.5 Original submitter: apepin Description: Steps to reproduce: - start AS - attach debugger - create Sync sample application in the directory SynchronousSample - create one more Sync sample application in the directory SynchronousSample1 - compile and deploy SynchronousSample1Application - set breakpoints in both SynchronousSample and SynchronousSample11 BPEL sources but in different lines - run test for SynchronousSample1Application Results: Process stops at both breakpoints.
*** Issue 79289 has been marked as a duplicate of this issue. ***
Alex Zgursky has fixed this issue
The bug is still reproducible in build 060806_1
See also http://www.netbeans.org/issues/show_bug.cgi?id=54358
A discussion in http://www.netbeans.org/issues/show_bug.cgi?id=54449 is also interesting
I could also reproduce the bug with a bit different scenario: - create two Sync samples - modify them a bit to distinguish one from another - deploy one of them - set breakpoint in both processes at the first receive - open the process you did not deploy - start debugging - execution will stop in the wrong process at the breakpoint - press Step Into IDE will not switch to different process
While I can see that such a behaivor may be confising for users, I'm not sure if this to be considered as a bug: In the "Attach Debugger..." approach you don't have a notion of the project being debugged. You debug the whole server (BPEL Engine), not a particular project. That's why if you have two or more versions of the same process opened in the IDE (process is identified by its QName - target namespace and local name) and you have a deployed process with the same QName, there is no way you can bind a server process with some client one. So, if you have breakpoints set in both of your local versions - they are both applied. Possible solution may be to identify such a situation when it occures and ask a user - does he or she want to apply all the breakpoints or just particular project's breakpoints. Or, maybe better approach would be to implement "Debug Project". With such an approach the project being debugged is known in advance.
See also #89292
Fixed, finally... Most part of the fix is really an implementation of issue 88625. In short, now we have "Sources View" working with BPEL Debug Sessions. When you start debug session - the Sources View is populated with all the BPEL files that are included in all the opened BPEL Projects. In the Sources View user can select those files which he/she wants to take part in debugging and which he/she doesn't want. If user starts a debug session by attaching a debugger - all the files are selected for debugging. If user starts a debug session by invoking "Debug Project" on Composite Application - only BPEL files that are related to that project are checked for debugging. That was about the feature 88625. Now about the bug itself. This bug was reproducing when there were more than one BPEL file that had the same QName (target namespace + process name) and a process instance of that QName was started. In that case BPEL Debugger didn't know which file to show to a user. So, the fix is that when such an ambiguity is detected by BPEL Debugger - it asks a user - which file he/she wants to use for debugging. User's choice is "remembered" in the "Sources" view.
Fix is not in Gavotte build 070216_2. Will try a new build later.
Tested with build from 2007.02.17 Verified