[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] How can you access an aspect from a normal java class

Piers Powlesland schrieb:
> I have tried the following form but Eclipse gives the error 
> "TestAspect cannot be resolved".

Ramnivas Laddad schrieb:
> The code seems right. Check your import statements and/or your 
> Eclipse setting (AspectJ nature, inclusion of TestAspect on source 
> path, etc.)

This is a well-known and sometime quite annoying problem of
the Eclipse tooling (AJDT). It is not really an error, i.e. if
the Project has AspectJ nature, you won't see an error reported
in the Errors view and of course when compiling with the AspectJ
compiler, the code passes without problems.

But as long as you use the normal Java editor for the source file,
the problem marker will be there and the Source together with the
whole package in the package explorer will show an error marker.

If I understand the situation right, the cause of the problem is
that the Eclipse Java tooling fails to expose viable extension points
for an Java based extended language (like AspectJ). This forced the
AJDT developers to re-develop an AspectJ version of the editor.


Though this might seem like a merely cosmetic issue, in practice
it's quite serious: Java developers working much with Eclipse tend
to rely on the markers (and the refactoring support) to quite some
degree. I saw projects where the use of AspectJ was altogether
ruled out and turned over by the "Java only" guys just because
of this issue. They would have accepted a changed compiler
and an modified build process, and they would even accept
a library aspect to hook into their code magically as long
as they aren't forced to change their working habits and
as long as the library aspect doesn't cause problems.


In this situation it is possible to circumvent the problems:
- keep the Aspects completely separate
- define annotations used by aspects in separate, normal Java files
- instead of using aspectOf in java code, use some depenency injection,
  e.g. use Spring to wire the setters, or make it an public field in
  the *Java* class and use another aspect to do the wiring.


Hermann V.