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 <ebenza...@gmail.com> 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 = (URL) nameMap.get(className);
> if (url == null) {
> String classFile = className.replace('.', '/');
> url = loaderRef.getClassLoader().getResource(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
>
> <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.clem...@gmail.com
> <mailto:andrew.clem...@gmail.com>> 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
> <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 <ebenza...@gmail.com
>> <mailto:ebenza...@gmail.com>> 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
>>
>> <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
>> <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@eclipse.org <mailto:aspectj-users@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org>
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> <https://dev.eclipse.org/mailman/listinfo/aspectj-users>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
