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.

Bug 52273 - automate debug.classpath closure
Summary: automate debug.classpath closure
Alias: None
Product: javaee
Classification: Unclassified
Component: EAR (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Konecny
: 174818 (view as bug list)
Depends on: 47507
  Show dependency tree
Reported: 2004-12-09 19:01 UTC by Vince Kraemer
Modified: 2010-03-30 12:52 UTC (History)
5 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Vince Kraemer 2004-12-09 19:01:16 UTC
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.
Comment 1 _ ludo 2004-12-20 18:40:48 UTC
projects in the web-inf/lib?
What does that really mean?
Reassign if you cannot fix this in your area.
Comment 2 Vince Kraemer 2005-02-07 18:32:09 UTC
j2se doesn't do this either.

changing to enhancement.
Comment 3 Martin Krauskopf 2006-09-11 16:29:32 UTC
J2EE team support ends, thus returning the issue back.
Comment 4 David Konecny 2007-10-22 15:08:06 UTC
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.
Comment 5 Vince Kraemer 2007-10-22 16:37:34 UTC
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....
Comment 6 David Konecny 2007-10-23 10:56:48 UTC
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.
Comment 7 David Konecny 2009-10-28 20:37:25 UTC
*** Issue 174818 has been marked as a duplicate of this issue. ***
Comment 8 bht 2009-10-28 21:13:53 UTC
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?
Comment 9 Vince Kraemer 2009-10-28 21:25:14 UTC
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.
Comment 10 David Konecny 2009-10-28 21:38:20 UTC
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.
Comment 11 bht 2009-10-28 22:47:36 UTC
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.
Comment 12 David Konecny 2009-10-29 10:24:45 UTC
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.
Comment 13 David Konecny 2009-11-02 02:12:20 UTC
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
Comment 14 bht 2009-11-02 06:05:40 UTC
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
This depends on

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.
Comment 15 Quality Engineering 2009-11-04 22:30:02 UTC
Integrated into 'main-golden', will be available in build *200911041401* on (upload may still be in progress)
User: David Konecny <>
Log: Issue #52273 - automate debug.classpath closure in EAR project
Comment 16 Martin Schovanek 2010-03-30 12:52:34 UTC