RE: Classpath problem

"Burgess, Jay S" <[email protected]> Fri, 28 Apr 2006 17:11:20 -0400
Newsgroups gmane.comp.java.jswat.user
Message-ID <[email protected]>
Nathan,

Thank you for the prompt response.  Everything you say makes complete
sense.  However, unless I'm misunderstanding something, the workaround
doesn't really solve my problem.

My servlet source is available in the Sources tab whether I'm Attach'ed
or not. But when I'm not attached, I have no error stripes.  After I
attach, however, the error stripes usually appear. =20

Your description of the classpath handling sounds right, but there must
be some combination of classpath AND sourcepath after I Attach that
causes files that are available on the sourcepath to suddenly be
considered "cannot find symbol".
=20
This isn't a major issue for now.  I just wanted to make sure I wasn't
missing something obvious.

Great piece of code by the way!

Jay


-----Original Message-----
From: [email protected] [mailto:[email protected]]=20
Sent: Friday, April 28, 2006 3:34 PM
To: Burgess, Jay S
Cc: [email protected]
Subject: Re: [jswat-user] Classpath problem

Two good points here, one is the Fix Imports action should be hidden.
Without a properly configured classpath it will zap many of the import
statements in your source file. Editing by hand is fine, that's up to
you,
but the debugger should not expose actions that quickly lead to
problems.
So, don't run the Fix Imports from JSwat; it will be removed in the next
release.

Second, about the classpath. It is poorly documented, but when you
attach
to the debuggee, the classpath from the debuggee is what takes
precedence
over anything you've set in the debugger. So, at a minimum that needs to
be more clearly documented. Ideally, the debugger should merge the paths
from the session settings and the debuggee.

Now, as to why you still see red error stripes: the Tomcat classpath is
probably only a minimum of the jars needed to bootstrap the system. From
that point onward, it uses custom classloaders to load everything else
(NetBeans has this same "problem"). As far as the debugger knows, the
classpath of the debuggee is just the stuff that's in the -cp argument
used to launch the debuggee.

You can work around this by getting the Tomcat source and adding it to
the
Sources session setting, but that would be overkill. The error stripes
are
harmless and you can safely ignore them.

I'll look into the merge solution, since it seems easy and avoids the
misleading error stripes.

Thanks

n


Jay Burgess wrote:
> I've read the FAQ, searched the list archives, etc., but still can't
> resolve the following issue:
>
> I'm running a servlet in Tomcat 5.0.19 (on Windows XP) and seem to be
> able to connect and debug using JSwat 3.10.  However, there is one
minor
> problem, that I think is associated with the classpath.
>
> I first start Tomcat.  I then bring up JSwat and set my classpath and
> sourcepath in the Session Settings dialog.  Everything seems to
resolve
> correctly, and I can see and open all of my source files from the
> Sources tab.
>
> However, sometimes after I "Attach" to Tomcat, I get hundreds of
"cannot
> find symbol" errors in my source with wavy red lines below.  Oddly
> enough, I can still set breakpoints and step through the source, and
it
> only seems to happen some of the time (though I can force it to happen
> by running "Fix Imports" at this point).
>
> I noticed specifically that the settings in the Classes tab change
> before and after I Attach.  Before, my correct .jars were present.
> After, only tools.jar and bootstrap.jar were listed. I believe this is
> fundamentally the root of the issue.
>
> So, is there a way to force my original classpath setting to stay
fixed
> after Attach'ing?  Or is there some other solution that will allow me
to
> debug given my configuration?  I also tried launching Tomcat from
JSwat,
> thinking that this would force it to hold onto the classpath I
defined,
> but never could get the config details right. (For reference, I
> currently call "catalina.bat jpda start" after setting the necessary
> envvars.)
>
> Thanks.
>
> Jay