Re: [aspectj-users] How to ensure AspectJ aspects are LTW'ed by Wildfly'

[Andy Clement <andrew.clement@xxxxxxxxx>]

Did you try your aspect jar on the bootclasspath ? (Just wondering if that might help).

AspectJ deliberately avoids getting involved in class loader shenanigans because it gets too complicated, hence relying on the delegation model in place for the system it is being used with.  However you make a ‘common jar’ available to all the individual module loaders in wildfly should work for AspectJ, unless they are handling delegation for classes differently to delegation for resource access. I don’t feel this is a new problem though, I feel it has come up again and again over the years - surely somebody solved it by now.... Did you try stack overflow? Sorry i don’t have any concrete answers.

 

cheers,

Andy

On Oct 26, 2017, at 11:37 AM, Eric B <ebenzacar@xxxxxxxxx> wrote:

Thanks for the info.  I've been digging through AJ and WF code some more to try to figure this out, but am still not sure how the classloader is working.  I'm starting Wildfly using the following arguments:

-Djboss.modules.system.pkgs=org.jboss.byteman,org.aspectj,test.aspectj,org.jboss.logmanager

-javaagent:c:/dev/tmp/jboss-eap-7.0.0/modules/system/layers/base/org/aspectj/main/aspectjweaver-1.8.10.jar

-Dorg.aspectj.weaver.showWeaveInfo=true"

-Dorg.aspectj.weaver.loadtime.configuration=file:c:/tmp/poc/aop.xml

-cp C:/dev/Projects/jms/mixed-arch/ear-app/aspectj/target/aspectj-0.0.1-SNAPSHOT.jar

So in it, I've defined an additional classpath pointing to my aspectj.jar file.  My /tmp/poc/aop.xml contains the aspect definition of "test.aspectj.TestAspect".

I can now see that the AJ agent is looking for test.aspectj.TestAspect class.  But it still isn't able to find it; I get the following errors thrown my the AspectJ Weaver: 

2017-10-26 12:11:39,889 ERROR [stderr] (MSC service thread 1-7) [ModuleClassLoader@336f62a1] info register aspect test.aspectj.TestAspect

2017-10-26 12:11:54,632 ERROR [stderr] (MSC service thread 1-7) [ModuleClassLoader@336f62a1] error The specified aspect 'test.aspectj.TestAspect' cannot be found

I've confirmed that my class (test.aspectj.TestAspect) is indeed in the aspectj-0.0.1-SNAPSHOT.jar.

So I get the impression that the aspectj-SNAPSHOT jar is not being made visible to the individual module classloaders.  I've tried to debug the weaver, and can see that it does indeed do the following:

private URL toURL(String className) {

URL url = "" nameMap.get(className);

if (url == null) {

String classFile = className.replace('.', '/');

url = "" class="">Resource(classFile + ".class");

nameMap.put(className, url);

}

return url;

}

where the loaderRef.getClassLoader() looks like it is the classloader that is passed to the ClassFileTransformer.transform() method (https://docs.oracle.com/javase/7/docs/api/java/lang/instrument/ClassFileTransformer.html).  But I'm not sure where/how to continue digging from here.  Which classloader is this?  Is this the base java classloader?  If Wildfly defines its own classloader (not sure if it does), will it be used instead?  On the other hand, if the base java classloader is passed, why is the classloader not able to find my test.aspectj.TestAspect class if it is in the jar that is part of my -cp arguments?

Thanks,

Eric

On Mon, Oct 23, 2017 at 1:45 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:

Yes, it is a bit specific to wildfly but I can talk to what AspectJ does.  I will also call out to an old article I wrote on debugging LTW: http://andrewclement.blogspot.ca/2009/02/load-time-weaving-basics.html (might be useful).

In the source for ClassLoaderWeavingAdaptor you will see three options for files we look for:

META-INF/aop.xml  — the regular one

META-INF/aop-ajc.xml — another option, useful in case you are using -outxml to generate the XML and don’t want to damage some user config you are maintaining (keep user stuff in aop-ajc.xml)

org/aspectj/aop.xml — for OSGi usage but not specific to OSGi, can be used in other scenarios.

Also in the same class you’ll see:

private final static String AOP_XML = Constants.AOP_USER_XML + ";" + Constants.AOP_AJC_XML + ";" + Constants.AOP_OSGI_XML;

String resourcePath = System.getProperty("org.aspectj.weaver.loadtime.configuration", AOP_XML);

So you can override those 3 places and give it the path to something else if you want to by specifying that property. If the thing you provide starts with file then it will actually load direct from there:

if (nextDefinition.startsWith("file:")) {

try {

String fpath = new URL(nextDefinition).getFile();

File configFile = new File(fpath);

If you just run default then it will be making calls to getClassLoader().getResources(name); for those three variants above. So you are at the mercy of whatever the class loader is allowing you to see.

cheers,

Andy

On Oct 21, 2017, at 7:19 PM, Eric B <ebenzacar@xxxxxxxxx> wrote:

So this is probably more of a Wildfly question than an AspectJ question as such, and I have already asked the Wildfly team about it, but I thought I would try to get additional clarity from the AJ pros to understand exactly how the LTW agent works.

My use case is that I want to use use AspectJ to advise some core classes in Wildfly/undertow.  Specifically, I'm trying to advise some of the Undertow HttpSession methods to get some more detailed logging when Sessions are created/expire/etc.

To that extent, I've added AspectJ as a -javaagent which is launched on startup of Wildfly.  I had to follow some of the steps listed at: https://github.com/ChienChingLee/How-to-launch-Wildfly-9.0-with-AspectJ-1.8-LTW.  But it works; I can see that the AJ weaver is loaded and present.

My problem now has to do with the way that the Wildfly classloaders work.  From my understanding, to avoid class conflict issues, the Application Server is designed such that everything is broken down into individual modules, with a separate classloader for each module.  Modules can declare dependencies on other modules if they truly want/need to access classes defined in a different module (see https://docs.jboss.org/author/display/WFLY10/Class+Loading+in+WildFly)

I've tried to configure AJ to have the loader available to all modules, so now my question is how does AJ detect Aspects in the classpath?  Where/how does it search for the aop.xml file?  Does the weaver search every jar that is in the classpath for these files?  How does it determine which files to scan in the classpath?  Does it simply delegate that to the classloader?  (ie: Class.getResourceAsStream("aop.xml"))?  I haven't dug through the AJ code to see exactly what it does.

Right now, I'm a little stuck in that I'm not sure how to ensure that my Aspects are loaded with every module in WF.  I've managed to reconfigure a single module and it works, but the idea of reconfiguring every module individually doesn't make sense.  

I tried to create an independent module in WF for it, and declaring it as a global module but that didn't seem to work.  

I tried to add it to the startup parameters in the WF startup configuration file, specifying it as -classpath path/to/myaspect.jar, but that only advised the startup WF (org.jboss) classes and none of the modules.

Can anyone shed some more light how the LTW works in order to search/find and weave classes?  Or if anyone has any brilliant ideas how I can configure my WF server such that I can drop my asepcts.jar in a "generic" place to make it woven into every module, I would appreciate it.

Thanks!

Eric

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users