Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] debugging aspected code

What Mark wrote is true but might be confusing to readers;
because we build on the eclipse compiler, they might think
that the eclipse bug needs to be fixed before .class files
produced by AspectJ support JSR-145, which is not true.

AFAIK:

- if the line in question is not in an aspect, 
  everything should work as usual in 1.0 and 1.1
  (if not, it's a bug).

- .class files produced by AspectJ 1.1 do not comply
  with JSR-45, but those produced by 1.0 do.  This is
  currently a known bug/limitation.

- i.e., if the line in question is in an aspect
  and you are using AspectJ 1.0
  and your VM and your debugger client support JSR-45,
  then you should be able to step into and out of the
  aspect source and set breakpoints there.

- The eclipse debugger does not support JSR-45, but
  Sun's jdb in J2SE 1.4.1 does (and others might as well).

- For AspectJ 1.1 to support JSR-45 means fixing the
  weaver and BCEL.  I am not sure if this is required 
  before 1.1 goes final (though I'd like it to be).

Wes

For those less in the know, here's some more detail 
and background:

AspectJ 1.0 supported JSR-45, but AspectJ 1.1 support
still needs to be developed, last I heard.  (BCEL needs to
be upgraded to pass the information through.)  I believe
that
ordinary line number information is still available, but I
haven't checked.

There are two ways to associate line numbers in .class
files, 
the old way and JSR-145 (which supports having many source
files 
for a class (etc.).  Running an application on a VM that 
supports JSR-45 (like Sun's 1.4.1) makes both forms
available
to a debugger client of the VM debugging API's (JPDA). 
Those
clients that use the high-level API's strictly should work
w/o
upgrade with the JSR-145-supplied lines, because they don't
change the debugger interface.  However, many debuggers make
assumptions that violate the API (e.g., the relative
location
of types, etc.).  The eclipse bug suggests that the Eclipse
debugger is one of these or that it uses lower-level API's.
In J2SE 1.4.1, Sun's jdb works to step through aspects.

Mark wrote:
> 
> chris,
> 
> pls look at http://bugs.eclipse.org/bugs/show_bug.cgi?id=25798 which
> describes the
> current situation. you can also search the eclipse.technology.ajdt
> newsgroup
> (look for 'jsr 145').
> 
> the problem is, that *eclipse* must support jsr 145 in order to allow
> you to debug code
> that has aspect stuff weaved into.
> 
> -- mark
> 
> Chris Nelson wrote:
> 
> >I've just begun my first forays into AspectJ and like others, am amazed
> >and impressed.  But before I could really be able to work with it for
> >real world stuff, I need to get debugging working and am not having any
> >luck thus far.  I am using AspectJ 1.1.b2 and using the iajc ant task to
> >do builds.  When I then attempt to debug code that has been touched by
> >an aspect, my debugger (Eclipse 2.1) complains about not finding line
> >numbers, even tho I have tried passing both debug=true and
> >debuglevel="lines,vars,source" as attributes of the iajc task.  I don't
> >know if this is a problem specific to Eclipse or just a known issue with
> >the 1.1 beta, but I would appreciate any help.  Any info on how other
> >people are debugging Aspects (please include AspectJ version, IDE, JDK
> >version, and so forth) would also be greatly appreciated.  I don't think
> >I'm doing using any features new to 1.1 so I could downgrade AspectJ if
> >I need to.   But all in all, the promise of aspects just has me
> >drooling.  Awesome job, AspectJ team!
> >
> >Thanks in advance,
> >
> >Chris Nelson
> >
> >
> >
> >_______________________________________________
> >aspectj-users mailing list
> >aspectj-users@xxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> >
> >
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users


Back to the top