JBoss AOP - boy, was I an idiot
Posted by: Matt in Software development, Web tools, tags: JBoss, Software developmentThis past week I burned up dozens of hours trying to make JBoss AOP work in my .WAR file. Then I realized that I didn’t have to.
I have this application that is a WAR file full of web services. What I wanted to do was create an aspect that I could weave in to gather usage statistics on every web service called — the user, the amount of time spent, whether it was successful or not, that sort of thing — and write it to a table for analysis and reporting. Since we use JBoss as our application and web server (and a paid support contract), I decided to try JBoss AOP which is bundled with the Enterprise Application Platform.
So, I wrote my aspect, and started trying to hook it in. Man, what an ordeal. JBoss AOP (like many AOP options out there) allows compile-time weaving or load-time weaving of aspects. It also allows you a choice of XML-based or JDK5 annotation-based configuration of the weaving and specification of pointcuts. I tried all four combinations, and I believe I was successful at all four in getting the weaving done, because I saw the various tools telling me that pointcuts were matched and that classes were updated as a result.
But no matter what I did, the advice in my aspect never ran. JBoss saw the aspect and weaved it, it just wouldn’t do it.
I turned load-time weaving off and on in jboss-aop-deployer/jboss-service.xml. I changed the include and exclude filters. I packaged the aspect inside the war and outside. I created a .AOP package that included both the war and a separate jar for the aspect. I downloaded and installed the latest JBoss AOP and installed that over the paid-for one that we use.
And then I realized — I don’t need to do this.
See, we use a code generator to generate source code for our web services. The generated code is simply a web service enabled facade that we put in front of POJO’s containing our business logic. The web service facade simply decorates the business logic so as to expose the methods as web services, and is all generated. I could modify the generation template to do the statistic gathering as the delegation occurs (which I did in 30 minutes and was done).
I guess this was yet another instance of “think — really think — before you start coding.” Just because a tool is out there that does the job you are doing, it doesn’t mean you should use it (*cough*hibernate*cough*). As Larry Wall said, there is more than one way to do it, and in this case I forgot to be open to them all. Live and (hopefully) learn.
Entries (RSS)
You definitely have a good point here, make sure you take a look at all of your options. Your little saying “Cool > Useful” rings true. One thing that AOP gives you is keeping cohesion as optimal as possible. When you add more into your code generation, it is just more and more that is maintained in the code generators.
I wonder what was keeping the aspects from running, any ideas after the entire ordeal?
No, I still don’t know what the problem is. Undoubtedly it was something simple that I wasn’t doing, but I could not find it.
And you are right - we are repeatedly generating inline code that would be ideally in just one place. On the other hand, AOP sometimes causes confusion with debugging because the bytecode weaving causes differences between your source code and its instrumented binaries - there’s code running there that isn’t in your source file, and most tools do are not aware of the AOP weaving going on. So, as long as you aren’t version-controlling the generated code (and why would you?) there’s only a little downside to doing it this way.
As a side note, we do have a JBoss support contract and I did open a ticket with them on Thursday. Still haven’t heard from them….hmm…..