[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Can non-weaved classes be removed from generated jar after ctw
|
Hemal Pandya wrote:
On Thu, Jan 21, 2010 at 4:54 PM, Simone Gianni <simoneg@xxxxxxxxxx> wrote:
[...]
Nope, sorry, I didn't mean this. The target jar will contain everything on
the inpath, weaved on not.
In which case do you see any problem with my approach of stripping out
the unweaved classes?
Theoretically no, as long as when you then assemble the final runtime
environment you manage to place the correct jars in the correct order on
the runtime classpath.
Suppose you have class A and B in xyz.jar, class A gets woven while
class B does not. What AspectJ does is producing a xyz-woven.jar
containing both A and B, so that you can remove xyz.jar from you runtime
classpath, use xyz-woven.jar produced by aspectj instead, and you'll
have all the functionalities of xyz.jar (class B) plus things modified
by aspects (class A). Now, if you remove class B from the xyz-woven.jar,
then you'll need both jars at runtime, which menas you'll have two
different versions of the A class.
The JVM may load the woven A class or the non-woven A class depending on
the order of the jars on the classpath, the specific implementation of
the classloader, whether it honors or not delegation to parent class
loader, settings on endorsed/bootclasspath etc..
While it is theoretically possible to do this, it can (and usually do)
also cause a lot of problems due to duplicates on the classpath. If you
experienced the mess that used to happen (and still sometimes happens)
when you have a version of a jar in one place and another version on
another place (like two versions of Xalan inside Tomcat, this used to be
quite frequent a few years ago), then you know what I'm talking about.
If you have a way to solve those problems while in runtime, like you are
in perfect control of the runtime environment and/or classloading
process, then it can probably work.
However, another approach could be to weave each jar separately,
obtaining rt-weaved.jar, ds-weaved.jar etc. Each jar will contain
everything was present in original jar files but with weaved classes.
Then replace, in the runtime environment, each jar with its weaved
counterpart. This does not produce duplicated entries on the classpath,
nor increases the size of the runtime environment significantly.
Simone
P.S. you are weaving rt.jar, which is tricky. There are many messages on
this list about weaving into java internal classes, it is quite a mess
to put them at work cause AspectJ runtime itself depends on them.
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/
