Re: [ajdt-dev] aspectj nature on EJB/Web projects in WSAD 5.x?

[Andrew Clement <CLEMAS@xxxxxxxxxx>]

Hi Mike,

Let me comment on your note:

> this is complicated (so it seems to us: we have
thrashed on it for a couple of days now).
 
> we are trying to add aspectj (1.2, via the 1.1.4
plugin, per http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ajdt-home/Updater.txt)

> in an existing WSAD 5.1 project base. this is
a large existing code base, and want to do
> a whole variety of things with it via aspectj.

I'm glad the updater script worked for you :)  Are
you using WSAD 5.1.2 or base 
WSAD 5.1?  We have been testing mainly on WSAD
5.1.2. 

> we would like to be able to do one (or both)
of two things:
> 
> 1) tag EJB or Web projects with an aspectj nature,
allowing aspects to live 
> in these projects and instrument aspect behavior
into pre-existing code in 
> these projects.
>
> the first dies when we attempt to rebuild projects
of this sort, with a 
> "Compile Failed" error message, and
no additional information. reordering 
> the external tools builder elements in .project
has no net effect (though 
> it appears to be the aspectj builder that is
failing).

Ok, I assume you add the aspectj nature to the web/ejb
projects using the 'convert to aspectj'
option in the context menu for the projects.  This
switches out the Java builder and switches
in the AspectJ builder.  Now there is a known
bug in WSAD when working with EJB projects
that have the AspectJ nature.  The problem is
that the deployment tool for the EJB asks the
project for the Java builder - but there is non registered
so it fails (we removed the builder
and replaced it with our AspectJ one).    We
have had this fixed
in the WSAD codebase but there is no version of WSAD
containing the fix available yet.
I thought we worked ok with Web projects - so can
you look in the workspace/.metadata/.log file
and see what failure led to the Compile Failed error
- if you tell me what it is, hopefully
we can work out why it is failing for you?  I
will also send you a document that describes the
testing we have done with AspectJ and WSAD - that
may help you.


> 2) keep our aspects in a dedicated aspectj project,
and configure an eclipse 
> ant external tools builder wherever necessary
to drive the aspectj compiler 
> onto existing projects, to instrument aspect
behavior into pre-existing 
> .class files (not jars) in those projects.
>
> the second (using iajc) dies with a NoSuchMethod
exception on a method 
> "org.eclipse.jdt.internal.compiler.Compiler.setCompilerAdapterFactory(..)"

> that doesn't exist anywhere i can find it (in
WSAD 5.x or in eclipse 3.X, 
> no jdtcore.jar i can find seems to have this
method on class Compiler).
> any help would be appreciated.

The AspectJ compiler is based on the JDT compiler
(a particular version).  I think
the problem you are seeing here is that your ANT invocation
of the iajc task is
not including fork and forkclasspath.  Without
saying :
  'fork="true" forkclasspath="blahblah/aspectjtools.jar"'
in your iajc call, the compiler is finding the eclipse
version of the Compiler
class rather than the version inside AspectJ.  The
version inside AspectJ
will have the setCompilerAdapterFactory() method.
 In new versions of AspectJ
we have changed the package name of the compiler we
take a copy of so this
doesn't happen.

Interestingly I've never seen anyone set it up in
this way - it should *work*
but I've never seen it used before.  I presume
you are setting the inpath
for the iajc task to bin the bin folder of the project
into which you want
to weave and then using the aspects in source form,
the result of the compile
going back into the bin directory of what was your
java project.  Navigation
of advice links in the editor won't work in this case
(as you compiled 'outside'
of AJDT using ANT) but it could be quite a performant
solution.

The way we would normally set this up is as follows.
 The AspectJ project
would have an inpath supplied (I think in the project
properties, 'non standard
compiler options' text field) that specified the bin
directory of the java
project - then when you build the AspectJ project
it would apply the aspects
to the class files from the java project and put the
output in the bin directory
of the AspectJ project.  However, if you want
to apply those aspects to multiple
different Java projects then your ant based solution
would be the way to go.

I hope that helps a bit? let me know if you still
have problems.

Andy.
---
Andy Clement
AspectJ/AJDT Developer.