Discussions

News: Symposium Presentation: Practical AOP - A Case for Aspects

  1. Bill Burke walks the audience through real world examples of applying AOP to everyday software development. Using the JBoss AOP framework, the audience will be taught how to build basic aspects, how to use JDK 5.0 annotations and AOP to actually extend the Java Language, use mixins to provide runtime APIs for aspects, use dynamic AOP for things like caches, use pointcuts for seemless transparent integration, and finally how to use AOP to test your applications in a easier way.

    Watch Practical AOP Presentation

    Threaded Messages (18)

  2. Berk[ Go to top ]

    Just what we needed after the Message-driven POJOs thread: more Bill Berk, this time waving his arms at us in a feeble attempt to convince us that JBoss AOP doesn't suck. And the silly cap doesn't help. Hani's right, what a whipping boy!
  3. Berk[ Go to top ]

    The part of his presentation that really suprised me was when he said that other AOP frameworks have been known to cause cancer.
  4. Re: Berk[ Go to top ]

    I just love it when people chime in on a topic without either using the product or watching/reading the content and then go whine about it. Can you site reasons why JBoss AOP sucks? Have you ever used JBoss AOP? Ever used AOP for that matter? Didn't think so.
  5. Re: Berk[ Go to top ]

    I just love it when people chime in on a topic without either using the product or watching/reading the content and then go whine about it. Can you site reasons why JBoss AOP sucks? Have you ever used JBoss AOP? Ever used AOP for that matter? Didn't think so.
    I don't think people are complaining about last 3 letters of JBossAOP, but about the first 5... ;)
  6. Berk[ Go to top ]

    Shouldn't it be JBoss AO ? :)
  7. Broken Link?[ Go to top ]

    The link to the presentation doesn't work. I get this instead.

    TheServerSide.com has recently ugraded its software. Every effort has been made to allow existing bookmarked links to pages within the site to continue operating. You are seeing this page because we were unable to translate your old-style bookmarked link to the new site (or, because there was a typo in the link URL you enterred into your browser's address field). We apologize for any inconvenience.

    The invalid URL was:

    http://www.theserverside.com/error/filenotfound.tss
  8. - Are there any real use cases for AOP except some simple tracing and timing tasks?
    - Doesn't AOP increase instead of reduce complexity of programs in the long run?
    - If it can be done with AOP it can easily be done in code, right?
    - Should one deliberately write impoverished code to be enhanced later with AOP?
    - ...
  9. - Are there any real use cases for AOP except some simple tracing and timing tasks?- Doesn't AOP increase instead of reduce complexity of programs in the long run?- If it can be done with AOP it can easily be done in code, right?- Should one deliberately write impoverished code to be enhanced later with AOP?- ...

    I probably shouldn't bother replying, but I'll bite.

    - Use cases: undo logic, design patterns, synchronization logic, etc.
    - Yes, AOP increases complexity in the short and long run, but it makes maintenance easier, just like OO.
    - Yes, you can do the same thing in "regular code," but you'll repeat yourself unnecessarily. AOP can turn linear into constant effort.
    - I'm not sure what you mean by the last question.
  10. Use cases: undo logic, design patterns, synchronization logic, etc.
    Is it like undo in a word processor, you can use AOP to undo changes made to a file? Or something else?

    Synchronization, is it like instead of synchronized(o) {blah} we can now use AOP to implement that logic?
  11. Use cases: undo logic, design patterns, synchronization logic, etc.
    Is it like undo in a word processor, you can use AOP to undo changes made to a file? Or something else?Synchronization, is it like instead of synchronized(o) {blah} we can now use AOP to implement that logic?

    Most likely he is talking about rollback logic. Ultimately, security, caching, remoting, logging, profiling, notification, exception handling these are items off the top of my head that would be both repetitive and orthongal to business logic.

    I've used AOP for security and caching and the clarity of the overall code is worth it. Notification, exception handling and profiling will most likely be next.
  12. Learning curve[ Go to top ]

    It is pretty steep. I have been trying to implement the undo logic for the past few days and I got tangled and scattered myself. How long will it be before we execute entire AOP projects ? Is AOP just for niche areas ? It looks like AOP is about design and not code.
  13. Learning curve[ Go to top ]

    It is pretty steep. I have been trying to implement the undo logic for the past few days and I got tangled and scattered myself. How long will it be before we execute entire AOP projects ? Is AOP just for niche areas ? It looks like AOP is about design and not code.

    AOP should not be used as a replacement to Object Oriented Programming, but rather as a compliment. You shouldn't force it in where it doesn't belong. If it is not clear where you should use it, then don't as you may cause more harm than good.

    That being said, to get into the feel of AOP, you should try things like declare-error/declare-warning. These get you used how pointcut expressions work. I hope they post Adrian Coyler's presentation as he talks a lot about how to introduce AOP to your organization.

    Another thing I suggest is focus on using AOP with annotations whenever approriate. One of the biggest problems in AOP is the fragile pointcut problem where your advice bindings don't match anymore because you've refactored your code, or, worse, you've written a pointcut expression the weaves in aspects where you don't want them to go. AOP + annotations in this scenario makes things a bit more explicit while still providing some flexibility.


    Bill
  14. Learning curve[ Go to top ]

    These get you used how pointcut expressions work. I hope they post Adrian Coyler's presentation as he talks a lot about how to introduce AOP to your organization.
    There are some good presentations currently on http://eclipse.org/ajdt/.

    I believe the the AspectJ/Eclipse book talks about coding rules enforcement, which is a good way to use AOP.

    AspectJ in Action (or the Eclipse Book) also talks about introduction AOP to yourself and your organization. The thing to do is start small and easy then go from there (if at all).
  15. Learning curve[ Go to top ]

    It is pretty steep. I have been trying to implement the undo logic for the past few days and I got tangled and scattered myself. How long will it be before we execute entire AOP projects ? Is AOP just for niche areas ? It looks like AOP is about design and not code.

    It sounds like your implementation choice may be steep. Spring's AOP doesn't implement the full suite of AOP functionality, but instead targets the one's they feel you are most likely to use. For me anyway, there guesses were spot on. Consider trying their implementation. The curve was actually pretty shallow. I had a dynamic proxy implementation that I wrote that took a few hours to "port" to Spring.

    If you need the entire world of AOP, Spring integrates with AspectJ, but you may find yourself up and running quickly with a different implementation.
  16. Learning curve[ Go to top ]

    I wish that the syntax stabilised. I started with AspectWerkz's Java syntax. When they introduced support for JDK 5, I learnt to use aspectwerkz Java syntax with annotations etc. After they merged with AspectJ I learnt that syntax. Now I am learning how to use AspectJ/JDK 5.0 syntax. I am learning to do the same thing over and over again. Now I have to learn Spring AOP ??
  17. Learning curve[ Go to top ]

    I wish that the syntax stabilised. I started with AspectWerkz's Java syntax. When they introduced support for JDK 5, I learnt to use aspectwerkz Java syntax with annotations etc. After they merged with AspectJ I learnt that syntax. Now I am learning how to use AspectJ/JDK 5.0 syntax. I am learning to do the same thing over and over again. Now I have to learn Spring AOP ??

    Well, you don't HAVE to. :-), it is just a suggestion. I picked Springs implemenation because I accept their philosophy and there software works. In addition, I accepted their premise that they've captured the aspects I'm most likely to use. In addition, there was talk of serveral of the AOP guys creating a common interface called the AOP alliance. Currently, those are the interfaces that I'm using. If the effort stalls, I'll most likely look to moving to Spring's specific implementation.

    From what I've seen, Spring has the simplest, least intrusive implementation. I personally prefer the XML configuration over the java syntax of AspectJ and the annotations of AspectWerkz and JBoss, but that is a preference.

    It took me only a few hours to convert my own dynamic proxy implementations to Spring's. I suspect that if you've looked at two other systems, you won't find Spring's daunting.
  18. Learning curve[ Go to top ]

    In my opinion AOP can be very helpful when developing complex applications. It is a shame that so many AOP presentation focus on the concepts rather than telling us where to apply AOP in a given application. Few people succeed in giving better examples than logging..

    It is my personal experience that AOP has its uses when it comes to writing non-domain code or business logic, i.e when it comes to infrastructure. Combined with i.e the Spring framework I think it proves its value. For instance; implement object caching declaratively - your business logic or data access tier don't have to know about it at all. Secondly - AOP can be used to handle security, like for instance the Acegi framework does. Apart from that I use Spring's AOP functionality for handling infrastructure related stuff that you don't want to mess up your code with.

    It does seem like a good idea to log all service invocations so that you can pinpoint performance bottle-necks and it does seem like a good idea to write your exception handler once and only once. Otherwise you cannot really know how exceptions are handled in your application.
  19. Using AOP for undo:

    http://blogs.codehaus.org/people/tirsen/archives/000690_undo_in_aspectj.html