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 user has to add the projects that are in the WEB-INF/lib of a webapp into the run-time configuration manually, to allow stepping into the code of the library during debugging.
projects in the web-inf/lib? What does that really mean? Reassign if you cannot fix this in your area.
j2se doesn't do this either. changing to enhancement.
J2EE team support ends, thus returning the issue back.
I believe that this is defect. J2SE project doesn't have this because there is no dependency model to follow and implement but that's not the case of ear project. Ear's debug classpath is closure of all web/ejb projects and jars they depend on.
Isn't the j2se dependency model the same: jars that a project depends on DIRECTLY + the closure of the projects that those projects depend on....
Re. "Isn't the j2se dependency model the same" - I think there is difference. In EAR project you explicitly storing all jars in one ear file the way it is required by J2EE spec (e.g. J2EE Optional Package Support). Similarly in Java Web Start you explicitly list all required jars in Web Start deployment file. But for J2SE jars it is implicit - there is no concept of deployment descriptor nor packaging mechanism. IMO this problem should be resolved in all projects, but in EAR it is a bit more urgent than in J2SE.
*** Issue 174818 has been marked as a duplicate of this issue. ***
The suggested workaround is to adding Wicket library to "Embedded Classpath Elements" in EAR's project properties (Libraries category). Thanks for that. A Web project as part of an Enterprise app cannot be debugged standalone. Therfore one could argue that this issue is not actually an enhancement but a bug. Why is this forgotten?
I guess I do not understand your comment.... A Web project as part of an Enterprise app cannot be debugged standalone. Please take a couple minutes to describe your expectation a bit more completely.
re. "Why is this forgotten?" - my opinion is that not many people probably bump into that issue because perhaps not many NB users debug web apps in EAR? I agree that it should just work, but I'm not sure about priority of this request (regardless of whether it is defect or enhancement). There is one duplicate after 5 years and 1 vote.
vkraemer, thanks for your kind words. With EJB 3.0, if I have a web project that depends on EJBs then I enclose it in an enterprise project that also contains an EJB module project, that one that the web module project needs. In that setup I cannot run the web project standalone (without the enterprise project). However, I always have to add my web libraries to the web project whether it is contained in an enterprise project or not. If I try to add the web libraries to the enterprise project then the web project does not compile. So normally, as a NetBeans user, I would never actually get the idea of adding web libraries to the enterprise project because it simply does not work for the web module. On the other hand, the developer has to run and debug the enterprise app not the web app. So from the perspective of a developer who expects the computer to work logically for them, the process is just broken. I would not count so much on this not being reported more often. Debugging on the GlassFish server has had quite a few bugs until recently, and for me, it was just a frustrating combination of them that had discouraged me to look into other things like this. The debugger has the option to disable library source code - NetBeans REALLY HAS a wonderful set of tools. This is how I want to do it not with workarounds. I would like to know why developers would not debug web projects within an EAR project. May be I can make my life easier.
bht, thanks, you raised some good points. I had a look at the code and I have a patch finished which collects all JARs used by J2EE modules packaged in EAR (that is all JARs which end up in EAR's lib directory) and collects sources for these JARs if they are available and passes these sources to the debugger. I plan to test it and integrate it early next week. That should address this issues. I will comment on your other points later.
9f4c7d4ce832. Fixed. bht, more or less FYI, the way I fixed this issue is that all JAR files in EAR's lib folder (see issue 163971 - all JARs which are not NetBeans J2EE modules are from NB68 placed to EAR's lib folder) will have Sources enabled during debugging if the sources are available. Any other comments, suggestions or verification of the resolved problem are welcomed and appreciated!
dkonecny, thanks very much for resolving this. The only comment I can make at this stage: During some debugging sessions some time ago, I was getting confused about breakpoints in source code in libraries that were included in the web project. Please read http://www.netbeans.org/issues/show_bug.cgi?id=155983 This depends on http://www.netbeans.org/issues/show_bug.cgi?id=152425 My concern was that if a source root is disabled in the debugger sources window for some reason, but the user nevertheless sets a breakpoint on a source line contained in above disabled source root, then this breakpoint is silently accepted but the user is not notified that the debugger will never stop on the breakpoint. This scenario could be a worthwhile test case for the new fix you did.
Integrated into 'main-golden', will be available in build *200911041401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/9f4c7d4ce832 User: David Konecny <dkonecny@netbeans.org> Log: Issue #52273 - automate debug.classpath closure in EAR project
v.