> I suspected that AJ just uses whatever classloader is provided to it.
Yes, exactly. Because we don’t want to get into tricks around classloaders. I am a bit rusty but I think for weaving a particular type you can see the entry point in the type Aj is driven every time something is loaded once you’ve registered the agent:
public byte[] preProcess(String className, byte[] bytes, ClassLoader loader, ProtectionDomain protectionDomain) {
This is invoked by the ClassFileTransformer (java.lang.instrument.ClassFileTransformer) implementation in AspectJ called ClassPreProcessorAgentAdapter
The class file transformer is passed the loader and the bytes for a particular class. From the loader we determine the weaver instance which gives us the context to weave the bytes. If that loader does not provide visibility to something, the weaver instance for that loader will not be able to see it. In your case if it is this module loader, and it is not delegating class/resource lookups to a parent then AspectJ will not find anything outside the module. I’d suspect there is a way to have common modules but I’ve no idea how wildfly allows that.
> So given that the AJ Weaver doesn't find the classes, I figure that WF is doing something with/to it.
Yep, me too.
> Do you know if there are any docs or whitepapers I can read up on how the classloader/instrumentation cycle works? I couldn't find enough clarity on the Oracle site.
Search up ClassFileTransformer but honestly, I might be wrong, but I don’t think that has much to do with it here. It is entirely down to how visibility from that loader should be setup in wildfly. Write some code that has nothing to do with aspects and don’t attach the agent. Something like this in your application:
Class.forName(“some type from aspects.jar”,false, this.getClass().getClassLoader()); - can that access them?
If it can what about:
this.getClass().getClassLoader().getResourceAsStream(…class file reference…) - can that see them too?
If those are true then AspectJ ought to be able to see them.
> I haven't tried posting on StackOverflow yet figuring that I would likely get a more targeted response from here or the wildfly-dev forums.
Folks like scoring points answering questions on stackoverflow - you might get a good answer :)
cheers, Andy
I did try with my aspect.jar on the bootclasspath with -Xbootclasspath/a (I would be surprised if /a or a /p would make a difference). Didn't make any difference.
I haven't tried posting on StackOverflow yet figuring that I would likely get a more targeted response from here or the wildfly-dev forums. But to date, it's tough to reconcile information from the two independent camps. :) I suspected that AJ just uses whatever classloader is provided to it. That's kind of what it looked like to me. But I couldn't/don't understand how the Agent bootstraps though. From what I can tell, its the base JVM's classloader that calls the Agent premain, and instructs it to instrument the classes. In which case, I would expect any visibility of that classloader to extend to AJ as well.
So given that the AJ Weaver doesn't find the classes, I figure that WF is doing something with/to it. But in that case, I dont understand at all how the JVM's instrumentation works; I guess I'm confused where in the cycle the instrumentation is called when loading classes. Do you know if there are any docs or whitepapers I can read up on how the classloader/instrumentation cycle works? I couldn't find enough clarity on the Oracle site.
Thanks, Eric
_______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
|