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.
I see the following exception sometimes using BPEL debugger: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1759) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.netbeans.modules.bpel.debuggerbdi.rmi.wp.impl.DefaultRMIService$RMIServerImpl$ObjectAdapterImpl$1.start(DefaultRMIService.java:1439) at org.netbeans.modules.bpel.debuggerbdi.rmi.wp.impl.DefaultRMIService$RMIServerImpl$ObjectAdapterImpl.run(DefaultRMIService.java:1502) [catch] at java.lang.Thread.run(Thread.java:619)
Alexander, please take a look.
Jun, if it's something that's being shown up in the console while it shouldn't - i.e. if it's harmless - the priority should be P3 or even better - P4. Have you noticed any incorrect behavior besides that log messages?
The key problem I had with the current design is that the "Debug (BPEL)" action is add to the context menu statically independent of the CompApp project content. The CompApp project may not have any bpel component, but the action is there and enabled. I have accidentally clicked on it a few times while trying to select other actions.. and it starts GF and deploys the project even when the CompApp project was empty!!!
Agreed. I've just filed issue 113242 for that.
I had a couple of problems with BPEL debugger. This RejectedExecutionException being one, the other one being breakpoint in BPEL doesn't work if I run debug a second time. However, I couldn't reproduce the second problem with the latest OpenESB installer on a different machine, so maybe there is something wrong in my local development environment. This RejectedExecutionException seems to be harmless. If it is indeed harmless, I suggest we put it into NB log quietly and don't show it in a popup dialog in the user's face. That way, I have no problem with P3/P4. I will create a separate ticket for Tien's complaint.
Ohh, you mean that there is a dialog window that shows up with the exception.. Then, it's probably a good candidate for P2. Although, I've never seen this exception (in a dialog) by myself. Could you please provide some info how to reproduce it? Is it when you are terminating a debug session?
As I said before, my local dev environment is a little wacky. But I did see the same exception with a fresh OpenESB installer on a different machine. I was pretty much doing the same thing. Anyway, this is how I got it in my local dev environmment: 1. Create TRS 2. Set breakpoint at line '<if name="HasHotel">' in BPEL 3. Debug compapp 4. Breakpoint reached 5. Continue => See the exception
Created attachment 46910 [details] exception
Correction: step 3 should be "debug the HasHotel test case."
Oh, I see now. I never use "Debug Test Case" feature and that explains why I never encounter such an exception. The possible problem is that "Debug Test Case" terminates the debug session as a test case completes, normally or due to timeout. Probably, it needs better synchronization. Also, AFAIR, "Debug Test Case" feature is not completed yet. I've seen some "TODOs" in the code about timeout and something else. I'm going to look into it.
Maybe you can work on the synchronization part and I will work on the timeout TODOs?
Sure
I have implemented a couple of TODOs for test case debugging: 1. Test case timeout is now disabled during debugging; 2. BPEL SE's "DebugEnabled" property is restored after debugging. I am not sure I understand the expected debug behavior on the project node though. Could you explain?
Not sure I understood you about behavior on the project node. Assuming you are mentioning "Debug (BPEL)" action, the original plan was to make something similar to that of Java Enterprise projects. It was supposed to: 1) establish a debug session and 2) "Run" a compapp application. Establishing a debug session was to make a lookup for available Debugger Engines and to ask user which engines to be used. For example, if user's compapp contains Java Enterprise, BPEL and XSLT modules - he/she could choose to use just BPEL debugger or just Java and XSLT. The default set of debugger engines to use was also to be configurable in the compapp Project Properties pane. For now we have only one debugger engine which supports debugging of compapp projects - the bpel debugger engine, so there's no need to ask user anything. And "Run" was supposed to be configurable from the compapp project properties pane - similar to that in Java Enterprise projects. There it was to be possible for a user to choose: whether to start some test case (default test case?) or do something else (e.g. open a web page in a browser - if our compapp contains Java Enterprise project). But for now "Debug (BPEL)" just establishes a debug session with the only debugger engine - the BPEL Debugger Engine.
Sorry, I hijacked this ticket for unrelated discussion. Without default test case, do you think the current "Debug (BPEL)" action is useful? Oh, I guess the user can invoke the "Debug (BPEL)" action to establish a debug session, and then invoke the "Test" action (on the CompApp project node) or the "Run" action (on the individual test case node) to do the actual debugging. Is that the idea?
That's right. That's how I use it.
Will address it after Beta1
*** This issue has been marked as a duplicate of 101603 ***
verified