Using AspectJ weaver and model
It is fantastic that JBoss is picking up AOP! AOP is a good antidote to much of the complexity making distributed systems hard to build.
I'm familiar with AspectJ, which has just released a beta of its open-source bytecode weaver, built on apache's BCEL. With this you can weave aspects into classes at load time. I believe the weaver solves a lot of the tricky problems with implementing AOP (e.g., inlining of advice, visibility of inter-type declarations (open classes), etc.). It seems to me that you could leap ahead of your current path by building on the weaver. One option for your implementation is to use the AspectJ weaver as a library to implement your limited model.
A more interesting option is to instead implement the AspectJ programming model for J2EE, using your deep understanding of the jboss runtime (e.g., doing cflow over distributed calls, implementing some form of distributed aspects), making you the first app server to do so. There are a fairly small (and non-trivial) set of requirements for doing this. Once the plumbing is done, programmers would enjoy the benefit of the full programming model, in their regular applications, or, if they are using J2EE, with JBoss.
Rolling your own AOP model is tempting to open-source developers, scratching the itch of what they need by implementing in the way they know how, and enjoying the learning experience along the way. But will what you end up with provide lasting benefit? JBoss is probably the best proof that open-source development can move faster and produce a better product than commercial development -- for well-understood programming models. But it's less clear that JBoss grows by pushing a new variant of AOP which can only be used in J2EE and only in JBoss -- including developing the tools and training the mindshare to get people to adopt a new model. AOP that happens with XML or during deployment is forced into the hands of specially-trained application assemblers and deployers, while general-purpose AOP can also be used by developers themselves, using a language as close to Java as possible.
As a tool component, the weaver could be used at any bytecode point, from the end of a Java compile through static analysis tools, RMIC, or class loading. The compiler does some whole-program analysis that might be quite fruitful to build other static tools with, or you might even be able to implement your JBoss variant model completely with binary aspects. That means the weaver could play a role at a number of points in your tool chain, and you might need only write the aspects themselves. That makes it more flexible from a feature-set standpoint.
As a business model, I imagine that JBoss would come out of the box with configurable aspects for doing the kind of high-level profiling or first-failure data capture that systems analysts need to understand their systems. Beyond that, JBoss consultants could sell configurable binary aspects (e.g., for caching), or build their own tools based on the weaver and compiler, reading aspects in binary or source form (even your current XML, if you insist!). All that is possible today with the AspectJ because it is open-source.
So this is what I see:
- you decided on your implementation strategy before looking at the bytecode weaver
- you're building your AOP model from the ground up as interceptors+ in XML, which is not a usable for most developers except for relatively simple problems
- your model is specific to particular itches of JBoss users, so it's not a growth feature.
This is what I recommend:
- using the open-source AspectJ bytecode weaver to implement your model
- implement the AspectJ model, which has evolved over three+ years of developer feedback about what makes sense and what doesn't.
I believe that AOP as a technique is orthogonal to the environments AO programs run in. The best thing for environments to do is to implement the standard programming model, which benefits both the environment and the model. I'd be surprised if you didn't get support from the AspectJ team and community in following this path.
I'm psyched about JBoss doing AOP in *any* form. But imho AspectJ is the best-available form and has the best chance of being widely adopted, and building on the AspectJ weaver is the fastest and best path for JBoss to bring AOP to J2EE.
Wes
