Personally, I think AOP where aspects are definted with XML is not a very good idea. You completely lose the power of the compiler and you are left to find your mistakes at runtime. And XML is just cumbersome and there is no way you could even come close with XML, to the power of the syntax AspectJ provides. Wes Isberg had a pretty good summary of some of the potential pitfalls of using XML in conjunction with AOP, I'll see if I can dig it up.
Sorry, I can't resist putting in my off-topic $.02.
First, the claim that XML-defined aspects can only be caught at runtime is incorrect. AspectWerkz, with XML definined aspects, can use the post-compiler approach just like AspectJ and report all compilation failures then.
Also, I totally agree with your point that aspects can often be misused when a plain-java approach would be much more understandable and straightforward.
Now, on to the opinionated portion of the post :) . I have used both AspectJ and AspectWerkz, albeit in a very limited way. My open-source project, VirtualMock, supports the use of both AspectJ and AspectWerkz in a transparently interchangable manner.
AspectJ is definitely more mature and powerful. It does currently support some features that AspectWerkz does not (but the AspectWerkz developers are steadily working to address these shortcomings).
AspectJ is also, IMHO, very hard to learn. I'm not ashamed to admit that the the AspectJ custom definition syntax often makes my head hurt when I try to understand it. Of course this is just a learning curve issue, but there is a lot of complex stuff to learn.
AspectWerkz, in contrast, is much easier to learn. The XML definition syntax is much closer to something that can be read and understood by your average human. The arguments against coding in XML are all valid, but it's definitely much more understandable than the AspectJ syntax.
This learning curve may be a non-issue for people who are really smart or have already learned AspectJ syntax. However, it is definitely a major issue, especially for projects with several developers, who are often distributed over a bell curve in terms of capability and motivation to learn a complex new programming syntax (just the concept of AOP is difficult enough for many people).
Now, the other point that hasn't been mentioned is the new AspectWerkz support for defining aspect functionality via "xdoclet" style tags. To me, this seems like the best solution in the long term. This is still "native java", and the future releases of the JDK will formalize this approach. There will still probably be some types of aspects that cannot be defined in this manner, but it makes sense to me to use this approach whenever possible.
Also, in my experience, I think it is best to make your aspects as "bare-bones" as possible. In other words, refactor out all the logic that is not directly tied to the aspect into plain-java helper utility classes. These can then be directly unit tested without worrying about the complication of the aspect framework. I think this is a good general approach to make your aspects more understandable and manageable.
Anyway, enough off-topic opinionated spew.
Thanks, Chad
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
