Version 10

    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