without the brackets...
?xml version="1.0" encoding="UTF-8"?
interceptor name="optimisticlockretry" class="biz.OptimisticLockRetryInterceptor"/
pointcut name="taskMethods" expr="execution(public static * biz.TaskMethods-addTask*(..))"/
pointcut name="templateTaskMethods" expr="execution(public static * biz.TemplateTaskMethods-addTemplateTask*(..))"/
bind pointcut="taskMethods OR templateTaskMethods"
I think you have to deploy your .aop file outside the EAR.
You're packaging everything in an EAR, correct?
If still need to package everything, just package everything in a JAR:
I think that will work. I'm not sure if plain jars can have nested archives though...so...if that doesn't work put everything in a SAR.
Let me know if that works.
I can try this deployment, but I'm not sure what to put in the jboss-service.xml in the top-level SAR file.
Yes, I have everything in an EAR right now. My install will look like this, assuming I can get a valid jboss-service.xml
-META-INF/jboss-service.xml // This is the one I need help with
try the JAR approach first. I think that works.
Its running with the new packaging, but it's still not running my Interceptor class. When I disassemble my instrumented classes, I don't see any references to my Interceptor class. Should I be able to see reference to the Interceptor in an instrumented class?
This is how my app is now packaged
-------------TaskMethods_addTask_5880466260420991488_OptimizedMethodInvocation.class (and others, you get the idea)
I've also tried putting the biz.OptimisticLockRetryInterceptor.class in the redrock-ejb.jar, but I get the same result.
Again, if I don't have the required AOP jars, I can't see TaskMethods.class at all (thats the error I get). And I can see these files changed after running AOPC.
I'm missing something. Am I not setting something up right? Or, is AOPC running on my files but not getting the interceptor in there correctly?
Going to the web-console I realized I didn't have jboss-aop.deployer in the deploy/ directory anymore.
Once I put that in, it worked with the JAR packaging. Without that folder, it doesn't work.
Thanks for the help, but now I'm a little confused. My understanding was that using AOPC made this unnecessary (obviously it doesn't).
So, suppose I wanted to use JBoss AOP with precompiled classes in, say, Websphere. I'm assuming this would be the same as using JBoss without the jboss-aop.deployer folder. Isn't there a way to make this work? I had gathered that the deployer folder wasn't necessary with precompiled instrumentation.
At any rate, it looks like it is working. Our customers are running JBoss without the jboss-aop.deployer folder, and I suppose we could ship it with our app. However, my hope was to make it all encapsulated in our EAR file (or JAR file, as the case may be).
jboss-aop.deployer holds a couple of things:
the JBoss AOP runtime:
Aspects are bound when classes are LOADED even with precompilation. What AOPC does is to preprocess the bytecode to weave in the hooks. The aspects are not bound until runtime. The is late-binding.
Late-binding is important for a lot of reasons. ONe of which being you can configure your aspects and which aspects are bound on a per-deployment basis, but still not get the overhead of load-time transformation.
Hope I am making sense.
one other thing. the jboss-aop.deployer also provides a service that recognizes .aop jars and -aop.xml files that are in the deploy directory.
Makes perfect sense. I appreciate the help.