Discussions

News: AspectWerkz 2.0: Plain Java AOP, Java 5 Annotations, and EJB 3 T

  1. In this article, Alexandre Vasseur explains how to make use of the rich semantics of the new AspectWerkz 2.x AOP framework and its annotation driven approach to implement a subset of the EJB 3 specification with Java 5: annotation driven Container Managed Transaction (CMT).

    There has been a lot of hype around using AOP to implement declarative transaction management "à la" EJB 3, based on annotations, but there are still interesting things to explain and for those familiar with it but not with AspectWerkz, this is a good background to have.

    This tutorial first explains the way that is most intuitive for users familiar with proxy based frameworks and explains why this approach is not sufficient from an AOP design perspective. It then goes step by step into more AOP semantics details with AspectWerkz Java 5 annotation defined aspects, aspect abstraction and annotation driven AOP. The end result is a completely reusable implementation for the EJB 3 Container Managed Transaction specification with support for the @javax.ejb.TransactionAttribute to define transaction boundaries and @javax.ejb.Inject instance variable injection that simplifies JNDI based lookups. The implementation is not tied to any EJB container and will run without extra compilation phase than just a JVM option introduced by Java 5.

    Read the Article

    Threaded Messages (21)

  2. Very, very impressive![ Go to top ]

    I must say, that made me really impressed. AspectWerkz is really getting into shape!

    Great job, Alex and Jonas!
  3. Totally Impressive[ Go to top ]

    AspectWorks is getting really impresive.
    Padmalal.P
  4. Printer friendly version[ Go to top ]

    I think the printer version url should be http://www.theserverside.com/articles/content/AspectWerkzP2/article.html instead of http://www.theserverside.com/articles/content/AspectWerkzP1/article.html.

    ...
  5. Yawn...[ Go to top ]

    We've had this in JBoss AOP for awhile now...Glad to see you're following our lead.
  6. Yawn...[ Go to top ]

    humility my friend, humility.
    -Duc
  7. Yawn...[ Go to top ]

    We've had this in JBoss AOP for awhile now...Glad to see you're following our lead.
    Well, that was a very "professional" comment, Bill. Congratulations, your boss must be very proud.
  8. Yawn...[ Go to top ]

    We've had this in JBoss AOP for awhile now...Glad to see you're following our lead.
    Well, that was a very "professional" comment, Bill. Congratulations, your boss must be very proud.

    I think having attitude like that is going to not only help promote Java products, but also promote deeper 'arguments' on the issues developers deal with.
  9. POOR MAN!!!![ Go to top ]

    COMPLEX OF SUPERIRITY OR COMPLEX OF INFERIORITY?
  10. Yawn...[ Go to top ]

    Bill, you sad, sad wanker... Stop boring people with your pathetic ejaculations of jbossian professionanist vitriolic rants. I mean, if not for us, then at least for Iona, they must be really ashamed to see a former janitor behave like this in public. At least Mojo Jojo is fun and, it has to be said, technically proficient.

    To our gentle readers, may they notice that Scott Fergusson is the CTO of Caucho and the abysmal pit that separates his tone and attitude from Bill's. [I'm not affiliated with Caucho in any way]

    To our gentle editors, what does marking a reply noisy affect ? May I suggest a hall of shame ? Is there like a FAQ that touches these issues ? (I do realise that his message is rather noisy itself)
  11. another thing[ Go to top ]

    You won't want to use the same package name of the EJB 3 annotations for declarative tx and security. EJB3 is a proxy-based architecture. This means that this.callSomeTxAnnotatedMethod does not trigger those aspects and you will screw up the semantics of EJB 3 Containers when they are released. Same goes for @Inject as well.
  12. another thing[ Go to top ]

    Bill,

    This tutorial is not at all about hooking in an EJB 3 container, but is about writing a subset of an EJB 3 container yourself. When going thru this tutorial, you will learn how to use AspectWerkz given an interesting problem.

    I still don't get why you always claim that you "had this in JBoss AOP for a while". JBoss AOP does not have before and after / after throwing advices detailed in this tutorial, but has only around advice.

    If you were talking about annotations defined aspects, you should remember March this year at AOSD where you followed our course on AspectWerkz, where we were teaching you about this concept we had implemented since Sept. 03 (see our blog post).
    It thus took you one year to reach that stage - something you announced in Sept. 2004 (see your own blog).

    It also shows that this is perhaps not rocket science to implement this part of an EJB 3 container. I let everyone judge by himself.

    Alex
  13. ... which is really the interesting question.

    I mean, why should the transaction declarations be restricted to session beans? Or the security annotations for that matter. Why not let @TransactionAttribute work with any POJO.

    Then someone who just needed some transaction boundary support could just add an annotation where it was needed or was most elegant for their code instead of using EJB and a session bean.
  14. another thing[ Go to top ]

    JBoss AOP does not have before and after / after throwing advices detailed in this tutorial, but has only around advice.

    That's because before/after/after throwing is syntax sugar.
    It also shows that this[tx demarcation] is perhaps not rocket science to implement this part of an EJB 3 container. I let everyone judge by himself.Alex

    I agree. Tx demarcation is about the simplest "real world" aspect to implement. It was the first aspect I wrote for JBoss AOP years ago.

    I also agree with the previous poster that Tx demarcation should be usable outside the context of a session bean.

    But heed my warning on using EJB annotations to write aspects as they may clash if you run these type of aspectized code within an EJB3 container. We provide EJB behavior "a la carte" in JBoss AOP (for awhile now) and use the same base annotation names as EJB3, but the package name is different.

    Bill
  15. another thing[ Go to top ]

    Bill.
    JBoss AOP does not have before and after / after throwing advices detailed in this tutorial, but has only around advice.
    That's because before/after/after throwing is syntax sugar.

    If you still think that before and after advice is just syntactic sugar then I suggest that you take a look at the figures in our AOP Bench article.

    Then you will become painfully aware of that an AspectWerkz before or after advice (without using arguments etc.) are 13 to 16 TIMES faster than the JBoss AOP equivalent while regular AspectWerkz around advice is "only" twice as fast as the JBoss AOP regular around advice.

    E.g. before and after advice are mainly used for performance reasons. (With argument access they perform more than 20 times faster than JBoss.)

    Btw, why do you have to constantly post so negative and disparaging comments, and always claim that JBoss is so much better on everything?

    /Jonas
  16. another thing[ Go to top ]

    Btw, why do you have to constantly post so negative and disparaging comments, and always claim that JBoss is so much better on everything?
    Don't worry Jonas. Being a JBoss Group employee it's practically in his job description to be arrogant, lack humility and have a complete disregard for objective reality (hence his reference to being "in the lead", which of course is hilarious). It's the only way they can promote and sell their services, because if they were to offer *what is really there* noone would buy it.

    Still, I would like to thank Bill for reminding me why I don't work for JBoss Group.
  17. another thing[ Go to top ]

    JBoss AOP does not have before and after / after throwing advices detailed in this tutorial, but has only around advice.
    That's because before/after/after throwing is syntax sugar.
    It also shows that this[tx demarcation] is perhaps not rocket science to implement this part of an EJB 3 container. I let everyone judge by himself.Alex
    I agree. Tx demarcation is about the simplest "real world" aspect to implement. It was the first aspect I wrote for JBoss AOP years ago. I also agree with the previous poster that Tx demarcation should be usable outside the context of a session bean.But heed my warning on using EJB annotations to write aspects as they may clash if you run these type of aspectized code within an EJB3 container. We provide EJB behavior "a la carte" in JBoss AOP (for awhile now) and use the same base annotation names as EJB3, but the package name is different.Bill

    Nothing to justify your f*cking afirmation that "We have had this in JBoss AOP since some time now" ? Just dropping FUD than let it pass ? Old good practices huh ? Don't you have an alt to post these things ? Just to make it more "JBOSS posting" style ?
  18. Yawn Yawn ..[ Go to top ]

    There has been a lot of hype around using AOP to implement declarative transaction management "à la" EJB 3, based on annotations
    <br>

    I can implement a container to handle declarative transaction management using java 5 annotations without using AOP. Am I completely nuts ?
  19. Yawn Yawn ..[ Go to top ]

    I can implement a container to handle declarative transaction management using java 5 annotations without using AOP. Am I completely nuts ?

    I'm doing the same thing right now with my own container, even to handle view layer stuff with validations/conversions--

    http://hookom.blogspot.com/2004/11/practice-what-you-preach.html
  20. I am really pleased that AspectWerkz 2.0 uses a plain Java syntax and no longer requires a post-compile step.

    These are impressive engineering acheivements that (a) remove a major obstacle to the use of AOP in non-experimental projects, and (b) makes AOP code easy to work with in vanilla (Java 5.0 compatible) IDEs. Well done!
  21. The link to the printer friendly version of the document points to different article by Boner - not the correct one. Could somebody please correct this ?
  22. Here is the correct link:

    http://www.theserverside.com/articles/content/AspectWerkzP2/article.html

    (changed P1 in P2)

    Alex