p.s. If you’re still interested in
writing a Weblogic 8.1 classloading adapter, I’d sure be interested in
testing it. From what I found, this would be the heart of it, plus some
appropriate packaging (if I recall right, there’s a specific manifest
required). You would also want to include
-Dweblogic.classloader.preprocessor=aj.weaver.Aj5ClassPreProcessor as a startup
option).
package aj.weaver;
import java.util.Hashtable;
import org.aspectj.weaver.loadtime.Aj;
import
weblogic.utils.classloaders.ClassPreProcessor;
public class Aj5ClassPreProcessor
implements ClassPreProcessor {
private Aj aj;
public void initialize(Hashtable
arg0) {
aj = new Aj();
}
public byte[]
preProcess(String className, byte[] bytes) {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
return aj.preProcess(className, bytes, loader);
}
}
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