Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
WCL for 1.2 - was Re: [aspectj-dev] Progress towards 1.2 release candidate (and some actions...) 
Hi Matthew -

Matthew Webster wrote:



- For LTW, I still haven't heard why having a separate jar and
main class that creates a classloader and delegate wouldn't
be a good interface.  That should work in Java 1.2+ and creates
a testable interface.  I understand that it's not sufficient
for some more complex J2EE deployments, but it should work
fine for simple programs.  (I believe I submitted this as
a patch...)




For LTW main class, I meant in addition to the script, not
instead-of.  I understand the benefits of the scripts.


The problem with the main class approach is that we end up with a different
method for each JDK level and one that isn't complete for 1.3 and earlier.


I believe the main-class-delegation should just work for
any version of Java that supports our weaver, subject
to the limits for system classes (below).  The "complete"
solution might not be correct for those people who are
understandably hesitant to weave system classes.


When running from the command prompt a user expects the same behaviour as
running vanilla "java", something that can be achieved with 1.4 and 1.5
because we can either fully replace or instrument the default system class
loader. In 1.3 there are still dangling references to the old loader
(System.getClassLoader(), Thread.getContextClassLoader(), ...) which may
cause certain programs to malfunction.


Any kind of support in 1.3 more useful than none, even if
the command-line is not a drop-in replacement for java
(indeed, I think it's clearer when it is different).
And subject to that limit, it's the only solution that works the
same for 1.3 and later, while people would have to retest
their 1.4 and 1.5 scripts to ensure the differing deployment
works.

(We might also want an example/API that shows people how to do
embedded weaving.  Right now the only "public" API in
org.aspectj.weaver.tools is not one that could be used to
drive an embedded weaver.)

As for the system and context class loaders, this scheme shows
what (imho) is the right setup: classes loaded by the
system class loader are not affected, but classes loaded by
the application class loader are affected.  This by default
should include the context class loader, since any implicit
CCL is taken from the application class loader, and any
explicit CCL can be set up by the user.  (This is "right"
not as the best case for AOP (control all classes), but
as the best-available case (for not violating any licenses).

Another reason: avoid some pain by minimizing the classes on
the classpath when weaving, by having people weave just using
aspectj-weaver.jar, rather than aspectjtools.jar.  This is
something of a separate question; we could deliver a
separate aspectj-weaver.jar without a main-class attribute
and update the example scripts to use that, but it's a
convenient step to make the jar runnable...


This is awkward because while most users have 1.4 and many are now calling
for 1.5 we still support 1.3 for generated code. Unfortunately we can't do
a complete job of supporting LTW because of Java run-time deficiencies
(that other tools address via bootclasspath and HCR). Also having a
"launcher" doesn't feel right although perhaps it would make a good sample
instead.

BTW I can't find your patch on bug 31460.


Nor I at the moment, but I'll check it in if the
aspectj-weaver.jar is a go.

Wes

btw, looking at the code...

- I had assumed we'd enforce a one-WCL rule, but the code
searches parents.  What happens if there is a parent
weaving class loader that loads class ST, a supertype of T,
and T is loaded by a child WCL that has additional
aspects defined for execution(* ST.*(..))?  I don't think
having n>1 WCL's in the hierarchy is much more tenable
than having some aspects defined after some classes
they affect are loaded, which I think we've agreed will
not work in the general case.

- can we change WeavingClassLoader to IWeavingClassLoader?

- can we change GeneratedClassHandler to IGeneratedClassHandler?

- ... WeavingAdaptor (WeavingClassLoader loader)
   to WeavingAdapter (GeneratedClassHandler handler)?

Back to the top