What exactly are you referring to when you say
it's being modified or not?
In either case, to get the AOPized behavior, even if you pre-compile a class, an applicable xml file still needs to be either in the runtime's classpath (under META-INF) or defined in a system property. (Otherwise you'll get the plain behavior.)
Now I think I understand your question (sorry!). Yes, a precompiled .class is modified. You can verify by file size or decompiling.
In the Wiki it says that we can precompile our aspects and then run them inside the JBoss server. I've adapted the build.xml from one of the examples, and aopc runs on my Driver class, but I can't really tell if it's being modified or not. Should it be modified, or is it just an in-memory change?
My aspect seems to work though, it gets into the intercept when I run my small test. I just am using JMX so I need to put it into the server. But it works perfectly right up to the point where it tries to hit JMX ;)
When running inside JBoss microkernel you can either do precompilation or load-time transformation to get your aspects to work. What exactly is your question?
Try this for decompilers. It really demystifies the JBoss AOP framework and you can see our weaving is quite minimal.
I use cavaj.
Okay, yeah I saw .. oh duh. I'm looking at the wrong classes. Looking at the decompiled POJO, I see it now.
I was just curious because I tried just putting my .aop file in the deploy dir of JB4DR2 and it didn't seem to pick it up, so I thought I'd try precompiling, which was right, but I was looking at the wrong decompiled object.