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.
This is a usability issue about inconsistence between Run action in Web project and Run action in j2se. Problem: Create a simple web application, put a breakpoint to the index.jsp. Run the project. The server is started and the application is run correctly. Now invoke the Debug Project action. The server is started in debug mode and execution of the request is stopped on the breakpoint in the index.jsp. Finish execution of the request (CTRL+F5). So far everything is OK. Now invoke the Run Project again. The execution is stopped on the breakpoint again. So now the Run Project and Debug project are same action from user point of view. User expect running the application without stopping on breakpoint like it was in previous releases, like it is in java SE projects. If user wants to really run the application he has to Finish the Debugger session. I think that the Run action has to finish the debugger session automatically. Debug Project action should connect the debugger again then. BUt the current state is inconsistence with java se projects.
I agree with Petr. It is really weird that the Run action stops on a breakpoint.
I don't quite agree, as there are some other considerations. The current behavior tries to minimize the number of server restarts, so the user does not have to wait for 1 minute for the server to run after pressing the Run action. Also, noone says that the Run action should not run the server in debug mode, e.g. MS Visual Studio has something like "Run" (which runs the application in debug mode) and "Run without debugging" (which runs it in non-debug mode), and "Run" is considered the default. Either way, whatever we agree is the right behavior, I don't think this classifies as a P2 issue, the inconsistency is probably a P3 issue.
Visual Studio argument doesn't apply - it's something different. The fact that behavior of Run action (whether it stops or doesn't stop on breakpoint) depends on a history of recently used actions (Debug, Stop Session) is wrong UI, IMO. Another fact that Run its clear user doesn't want Run to stop on breakpoint - we have another action for this purpose. Just to make sure we're talking about the same thing. Currently I can do the following: A) 1. Put breakpoint into index.jsp 2. Run | Debug Main Project 3. Application stops on breakpoint 4. Run | Continue (Ctrl-F5) 5. Run | Run Main Project 6. Application stops at breakpoint B) 1. Put breakpoint into index.jsp 2. Run | Debug Main Project 3. Application stops on breakpoint 4. Run | Finish Debugger Session --- different than in A) 5. Run | Run Main Project 6. Application does *not* stop on breakpoint Now in *both* scenarios application server indicates in the Runtime tab that it runs in the debug mode even when I use Run Main Project. Maybe I'm doing something wrong, but I think the application should *not* stop on breakpoint in A scenario.
> Maybe I'm doing something wrong, but I think the application should *not* stop > on breakpoint in A scenario. I think it's just the matter of the viewpoint, from the viewpoint you describe A makes sense, from the viewpoint that I don't want to wait 1 minute for the server to restart, B makes sense. Anyway, do you agree with the P3 priority? P.
> I don't quite agree, as there are some other considerations. > The current behavior tries to minimize the number of server > restarts, so the user does not have to wait for 1 minute > for the server to run after pressing the Run action. But this is not the right solution and this is not the problem. If I'm a user, then it doesn't matter in which mode the server is running. I just want to run the application without stopping execution on the breakpoints. IMHO the right solution is start the server in debug mode. Then the Run Project action will not attach the debugger or disconnect the debugger, if is already attach. The execution will not be stopped on breakpoints even if the server is running on debug mode. The Debug Project just attach the debugger. So the server is started only once (in debug mode). > Also, none says that the Run action should not run the server > in debug mode, e.g. MS Visual Studio has something like "Run" > (which runs the application in debug mode) and "Run without > debugging" (which runs it in non-debug mode), and "Run" is > considered the default. As Jano wrote, the comparing with MS Visual Studio is not appropriate here. > Either way, whatever we agree is the right behavior, I don't > think this classifies as a P2 issue, the inconsistency is > probably a P3 issue. I still see a problem that we have broken inconsistently behavior of Run action in this release and it is the first reason why I marked it as P2. The second reason is that it is very visible for users. NetBeans user doesn't expect that after invoking Run action the execution is stopped on a breakpoint. I think the fix should be easy. The Run action should check whether the debugger is attached and if yes, then disconnects the debugger session. It doesn't have to restart server, just diconnecting. We can waive it, but still I think this is something what shouldn't happened without discussing this with nb-usability team in future. Also I agree with Jano, that behavior of Run action should not depend on what user did before.
Ok, you (and Stepan and Jano) are starting to convince me, ;-) except this: > I still see a problem that we have broken inconsistently behavior of Run > action in this release and it is the first reason why I marked it as P2. Consistency is not god. If it makes sense to do things differently (and Java SE apps are significantly different from Java EE applications), then we can do things differently. Also, the current behavior is better than the 5.0 behavior, not worse. > The second reason is that it is very visible for users. No. AFAIK, we don't have any complaints or reports of this from real users. How many people have complained about this?
How about using a magic term "UI regression"? :-D Seriously, the point is clear that also now the server is *not* restarted in B scenario. It just doesn't attach debugger. I think P2 is appropriate (from UI point of view), but I understand where we are in the release cycle, so feel free to decide whether it needs to be fixed for 5.5. I personally would fix it if there's still time and the fix is easy.
I don't think the bug could be resolved in NetBeans 5.5 in two days before FCS build. I suggest to waive the bug for NB 5.5.
Stepan, could you write, whether the fix is easy or not?
There is an easy and obvious workaround, we will not fix this for 5.5.
I agree with no fixing to 5.5 -> downgrading to P3.
The prepared solution is risky and introduce one dangerous use case.
this really looks like a j2eeserver issue... not a tomcat issue... since I have seen similar bug reports in the GF plugin 'space', too.
*** Issue 90056 has been marked as a duplicate of this issue. ***
Do we really want to fix this? After several releases we don't have any single complaint afaik.
Does not seem to be an issue.