[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Compiling and not weaving
|
Hi Andy,
thanks for your answer.
Unfortunately this is blocking parallel evolution of different aspect
packages, especially in a Maven based system, but not only in that case.
Not setting the aspect projects in the aspectpath during build is not an
option if they declare any kind of public IDT or mixins or the like,
while setting them makes your code bounded to them requiring a rebuild
if a new version arrives, which can happen quite frequently while you
are developing. This is true with any other non-aspectj dependency, but
when aspects come to play it gets worse, cause by definition they are
"crosscutting", so you never know how much of your code needs to be
rebuilt in order to eliminate stale references to non existing aspects.
Maven acts as a multiplier, cause thanks to transitive dependencies it
will further propagate existing aspects around.
I still think this is somehow a bug. There are at least three motivations :
- I could have no "direct" dependency in my code to that library. For
example, it could be simply a tracing library, of which i don't know the
internal structure, don't have the source code, and an error telling
that my class cannot be loaded because another, external and foreign,
class is not present, when I have no import clause in my class nor any
direct or indirect usage of it, is quite disappointing from a user POV
since the stacktrace effectively throws a ClassNotFoundException.
- If I don't DELETE the aspect class, but simply move the advice from
one aspect class to another or simply delete the advice, there is no
exception and the target class gets correctly reweaved. So, a temporary
solution is to avoid deleting aspects, and leave them empty (comment out
or remove all advices).
- Using -X options previously discussed in this thread, solves the problem.
While it is reasonable and obvious for the reweaving step to analyze the
class before reweaving, and to complain in the case where the class
cannot be loaded due to a missing dependency, it should not be an abort
situation if the missing dependency is an aspect class, cause the very
reason why we are reweaving is to add missing aspects ... and remove
missing ones (as it happens for advices). Probably because I'm still new
to AspectJ I cannot see the use case where simply ignoring this error
and removing advices from missing aspects would cause problems,
especially in a LTW situation.
On the other side, I understand how loading and analyzing a class having
symbols pointing to missing classes can be a problem, and how
determining whether the missing class was an advice or not is not simple
at all, that's also why the "don't weave, I know that there will be LTW
and aspects I'm using are unstable" way was the first one that popped to
my mind to avoid all this.
Anyway, I raised the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=250921 to report this.
Simone
Andy Clement wrote:
> That seems to be a new and different issue, feel free to raise it.
>
> Reweaving is currently defined to search for what was around before in
> order to do the reweave. So it isn't really a bug right now, it is
> telling you that it wanted to find the old aspect but could not and so
> did not continue. We can modify the definition of reweaving so that
> you can say 'yes, i know its gone but I dont mind' but i will need to
> find time to apply some brain power to it to think through the
> ramifications.
>
> cheers,
> Andy.
>
> 2008/10/14 Simone Gianni <simoneg@xxxxxxxxxx <mailto:simoneg@xxxxxxxxxx>>
>
> Andy, this is one of those situations :
> - I have a package (admin-inline) that used to define an around advice
> on Template+
> - I have another package (asteappalti-site) that defines a subclass of
> Template called BaseTemplate, that used to be weaved with that advice
> - Now, the entire aspect containing that advice is gone, the new
> jar is
> present in the classpath and LTW is in place
> - But unfortunately, the BaseTemplate still searches for the old
> aspect,
> LTW throws an AbortException, and nothing is working.
>
> Rebuiling asteappalti-site solves the problem. So the problem seems to
> be that LTW is not able to reweave if an aspect that was there is not
> there anymore. This is a bug, I suppose.
>
> SEVERE: defineClass
> Message: error at it/semeru/asteappalti/site/BaseTemplate.java::0 type
> org.apache.magma.inlineadmin.AddMenuToDefaultTemplate is needed by
> reweavable type it.semeru.asteappalti.site.BaseTemplate
> org.aspectj.bridge.AbortException: type
> org.apache.magma.inlineadmin.AddMenuToDefaultTemplate is needed by
> reweavable type it.semeru.asteappalti.site.BaseTemplate
> at
> org.aspectj.weaver.tools.WeavingAdaptor$WeavingAdaptorMessageHolder.handleMessage(WeavingAdaptor.java:596)
> at org.aspectj.weaver.World.showMessage(World.java:636)
> at
> org.aspectj.weaver.bcel.BcelWeaver.processReweavableStateIfPresent(BcelWeaver.java:1352)
> at
> org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1133)
> at
> org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:394)
> at
> org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:281)
> at
> org.apache.magma.tools.maven.JettyWeavingURLClassLoader.defineClass(JettyWeavingURLClassLoader.java:127)
>
>
>
> Simone
>
> > I do agree on that, in fact runtime exceptions are the blocking
> part,
> > and I'll try to keep an eye on them to raise bugs when they happen.
> >
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx <mailto:aspectj-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
