Hi Bo,
Configuring the use of a bootstrap
classpath can be tricky, as you’ve discovered. Like configuring any
multi-level classpath, you need to have a consistent set of classes that
reference each other. I have found it possible to use Alex’s technique
with fewer bootclasspath entries. Both of the following approaches have worked
for me, so you might consider trying the alternative (I think Alex recommends
using more items on the bootclasspath). The jars here are a little different
because of how we have packaged them for Glassbox:
Option 1:
set
JAVA_OPTS=-Xbootclasspath/p:java14adapter.jar
-Xbootclasspath/a:createJavaAdapter.jar
-Daspectwerkz.classloader.preprocessor=org.aspectj.ext.ltw13.ClassPreProcessorAdapter
-Dorg.aspectj.weaver.showWeaveInfo=true -Daj.weaving.verbose=true
set
CLASSPATH=aspectj14adapter.jar;aspectjweaver.jar
Option 2:
set
JAVA_OPTS=-Xbootclasspath/p:java14adapter.jar
-Xbootclasspath/a:createJavaAdapter.jar;aspectj14adapter.jar;aspectjweaver.jar
-Daspectwerkz.classloader.preprocessor=org.aspectj.ext.ltw13.ClassPreProcessorAdapter
-Dorg.aspectj.weaver.showWeaveInfo=true -Daj.weaving.verbose=true
I don’t know about the
NullPointerException, it seems unlikely to be a requirement to exclude Weblogic
classes because LTW works just fine with Weblogic 8.1 SP4 and JRockIt 1.4…
perhaps it is another bootstrap classpath configuration issue.
From:
aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Bo Zimmerman
Sent: Monday, May 01, 2006 11:02
AM
To: aspectj-users@xxxxxxxxxxx
Subject: RESOLVED!!! RE:
(RESOLVED?) RE: [aspectj-users] Important aspects ofJDK1.4weaving
Hello all --
In software development, when things
aren't working the way you expect, a programmer will sometimes begin a process
I like to call "Poking". Poking is the activity of altering
code, runtime variables, or build environment variables to see how they affect
execution, often in the hopes that your software will miraculously start
working, but at the least learning something about the nature of your problem.
Well, Poking has worked for me once again
to clear up the problems I was having with Alex's JDK14 weaving method in
weblogic, described here:
http://blogs.codehaus.org/people/avasseur/archives/001140_aspectj_5_load_time_weaving_with_java_13_using_aspectwerkz.html
First off, boot-time java.lang.NullPointerExceptions
that occur during classloading (see my previous post), while appearing very
very ugly, don't seem to have any impact whatsoever on anything. They
_can_ be eliminated from weblogic altogether by creating exceptions for the
following class packages:
javax/management/
weblogic/xml/
weblogic/utils/
weblogic/apache/xerces/
weblogic/j2ee/
weblogic/application/
weblogic/management/
Of course, if you need to weave with any
of those packages, that's another story. Since my own application didn't
require it, I have no idea what the weaving consequences of the boot-time
java.lang.NullPointerExceptions would be.
Secondly, ClassNotFoundExceptions, despite
being ugly in appearance, are even Uglier in impact. In my case the
problem was that I was including my Aspects in the same jar package
with my ClassPreProcessorAdapter. Since they were "jarred"
together, both the aspects (superfluous to the bootclasspath solution) and the
preprocessor (necessary to the bootclasspath) got thrown into the same
bootclasspath context. Without going into too much more detail, this
appeared to cause my Aspect classes to always be referenced
in the same context as that "meta" bootclasspath, even
after boot. Any other classes or packages which were being included
by the Aspect classes, but not included in the bootclasspath were
coming back ClassNotFound. Separating the two proved the solution.
Thirdly, and along those lines, including
extraneous or superfluous packages in the bootclasspath, for good reasons real
or imagined, WILL cause problems. Don't try it. Put only the
absolutely necessary stuff -- the classpreprocessor, aspectwerkz,
aspectj. Nothing more.
Fourthly, it is absolutely positively
necessary that the Hook.Plug command (shown in the URL as part of an ANT
script) be executed against the EXACT same Sun JDK tools.jar file that will be
used at runtime. It is not possible, apparantly, to hook.plug with an
older JDK version and pray for forward compatibility. It may work with
one version of the JDK, and crash the entire JVM on another. Don't try
it.
Hoping the lessons of my own bruises
benefit others,
- Bo Zimmerman