JDK 5.0 and loadtime transformations

[adamw]

Hello,
I tried to enable loadtime transformations using AOP 1.3 and JDK 5, and made it work only after I changed:
<mbean code="org.jboss.aop.deployment.AspectManagerService"
to:
<mbean code="org.jboss.aop.deployment.AspectManagerServiceJDK5"

Shouldn't it be like that in the distribution package? I did everything as it is in the manauls, e.g. copied the -jdk50.deployer, changed EnableLoadtimeWeaving to true and added -javaagent:pluggable-instrumentor.jar.

Cheers,
Adam

[kabirkhan]

Yes,

The 1.3.1 release contains some more aggressive commenting for doing this.

I'll add a task to the JIRa to make the deployers reference the correct service

[adamw]

Hello,
is there anything else I should do to make it work? I though I had it working when I saw some "22:10:04,063 INFO [STDOUT] [warn] AOP Instrumentor failed to transform org.apache.catalina.core.StandardContext" messages during startup (and OutOfMemoryExceptions at the end ...), but neither my very simple examples, nor in-jboss examples (from here: http://docs.jboss.com/aop/1.3/aspect-framework/examples/injboss/aopInJbossPackaging.html) work.

Cheers,
Adam

[oberon777]

Yes, I saw the same messages.

I am having a great deal of trouble getting JBoss 4.0.3RC1 and AOP 1.3 work together. Somehow, I managed to get the injboss example to work on Windows, however, the Linux version still remains disfunctional.

Are there people out there that have successfully deployed their aspects using this combination? I have difficulty adding aspects to injboss -- apparently, my aspects are not being found or something.

[bill.burke]

I did the 1.3.0 and 1.3.1 bundles. I tested them on Linux before deploying...

Make sure you are packing your aspects within .aop archives. If you are bundling .aop files within an EAR, make sure you have them EXPLICITLY listed in modules in jboss-aop.xml

[oberon777]

Thanks for your reply, Bill. Is the 1.3.1 bundle available?

I am adding my aspects to the war file the appilication is contained in, which is done by running ant deploy-basic-lt-war. This uses a standalone jboss-aop.xml file.

I am not using any *.aop files at all. Is that a problem? What's the search path for aspects listed in a standalone jboss-aop.xml file? I.e., if I have this

<?xml version="1.0" encoding="UTF-8"?>
<aop>
 <bind pointcut="call(* org.jboss.injbossaop.lib.ExampleValue->getMessage())">
 <interceptor class="CallerInterceptor"/>
 </bind>
...

where is CallerInterceptor supposed to be located?

[bill.burke]

So, your jboss-aop.xml file is wihtin your WAR? This will not work. The deployer will not look in WARs for aop.xml files.

[oberon777]

No, jboss-aop.xml is outside. I tried EAR deployment as well with the same effect.

Somehow, SimpleInterceptor in injboss doesn't fire. I don't know how to trace this issue. How can I figure out why that's happening?

Pointcuts specified in jboss-aop.xml are listed under AOP in Webconsole. However, all of them are listed as unbound. I have no idea why.

[kabirkhan]

Have you modified Include attribute of the aspect manager service to include org.jboss.injbossaop? e.g.

<attribute name="Include">org.jboss.test,org.jboss.injbossaop</attribute>
 <attribute name="Exclude">org.jboss.</attribute>

I have set this up by default in 1.3.1.

[adamw]

This solved the problem. I didn't read the configuration file carefully enough and didn't spot this, thanks for the help!

Are there any special rules for including/ excluding packages? Like if you write in the tag a package with a dot in the end (for example, org.jboss.), all sub-packages will be excluded, right? Does the dot in the end matter?

[bill.burke]

JBoss AOP does a String.startsWith to match an include or exclude.

If you specify an include, it will *always* be included, even if there is a matching exclude.