Running JBossAOP standalone (outside of application server)
JBossAOP can be run quite easily outside of the application server. You either have to have control over the system classloader so that JBossAOP can manipulate the bytecode of the loaded class at runtime, or you can precompile the bytecode with a precompiler.
Precompiler
JBossAOP comes with a precompiler that can bytecode manipulate your class files. You can run the precompiler on the command line or via an ANT target.
Running Precompiler on command line
$ java -classpath ... [-Djboss.aop.aoppath=...] org.jboss.aop.standalone.Compiler <class files or directories>
The class files you are instrumenting must have everything they would need to run in the java classpath, including themselves, or the precompiler will not be able to run. The jboss.aop.path optional system property points to XML files that contain your pointcut, advice bindings, and metadata definitions that the precompiler will use to compile the .class files. The property can have one or files it points to delimited by the operating systems specific classpath delimiter (';' on windows, ':' on unix).
New since JBoss AOP Beta2
The jboss.aop.path now also accepts directories as well. Any file of the pattern aop.xml will be loaded from a directory in the jboss.aop.path
The precompiler can also be run using an ANT task. The example tutorials all use the precompiler (aopc) so take a look at the build files there to see this in action.
Running with precompiled files
You must have the following jars in your classpath in order to run a JBossAOPized Java program
jboss-common.jar |
jboss-aop.jar |
javassist.jar |
concurrent.jar |
trove.jar |
qdox.jar for annotation compiler |
Again, the jboss.aop.path optional system property can point to XML deployment descriptors that JBossAOP will need to bind in interceptors and advices to your AOPed classes. Alternatively, if you do not like the system property approach, JBossAOP, by default, will look in the classpath for all URLs that match META-INF/jboss-aop.xml. This allows you to package your aop xml files into jars and have the jars in the classpath. Take a look at the packaging tutorial to get a better idea about this and see it live.
Running without precompilation.
To run without precompilation, JBossAOP must have full control over classloaders so that it can bytecode manipulate class files at runtime. It is a bit slower to startup JBossAOP in this manner, so precompilation is recommended. To run with load-time bytecode manipulation, use the following:
$ java -Djava.system.class.loader=org.jboss.aop.standalone.SystemClassLoader [-Djboss.aop.path=...] com.acme.MyApplication
NEW since JBoss AOP 1.0 RC2 or greater
If you're running with JDK 5.0, JBoss AOP has MUCH better support for load-time transformations using the java.lang.instrument package. This is a MUCH more reliable mechanism for AOP bytecode weaving.
$ java -javaagent:org.jboss.aop.standalone.Agent [-Djboss.aop.path=...] com.acme.MyApplication
Comments