Discussions

News: BEA dev2dev Releases AOP System for WebLogic

  1. NOTE: Information taken from Cedric's blog

    BEA has released a WebLogic Aspect Framework. This framework is based on AspectJ and is made of a set of predefined pointcuts that WebLogic users can simply reuse and write aspects for. The idea behind this design is that our customers don't really care about aspects, nor about learning yet another API (or even another language): they have some very specific needs need addressing in the simplest possible way.

    Grab the framework @ the dev2dev website.

    We have a pretty good idea now of what aspects mean for Java, but what exactly is a J2EE aspect?

    After thinking about this problem, BEA identified several areas of interest in J2EE that users might be interested in:

    EJB: constructors, CMP fields, business methods, finders, select methods
    Web: service(), jsp(), getSession(), tags
    JDBC: trace all the SQL statements, prepared statements
    JMS: onMessage(), message publication
    etc...
    and BEA defined pointcuts matching them. You don't need to know much about AspectJ in order to use this framework, and the examples included in the distribution should be enough to get started.

    For example, suppose you want to be notified every time findByPrimaryKey() is invoked on your EJB, the aspect is:

    before() : EntityEJB.findByPrimaryKey() {
      System.out.println("findByPrimaryKey: " +
              thisJoinPointStaticPart. getSignature().getName());
    }

    Note that this framework can be theoretically run on all versions of WebLogic back to 6.1. I say "theoretically" because it hasn't been tested on versions older than 8.1, and you will probably encounter a few regexp-related issues if you try to run it on JDK 1.3, but that could be fixedif there is enough demand. The point here is that this framework uses a system that has been in place inside WebLogic since 6.1.

    BEA created a mailing-list where the author of the framework (Sam Pullara) will be more than happy to assist you.

    How interesting to see a commercial vendor get into the AOP action in a fashion such as this. Kudos to BEA, and it will be very cool to see how people use this (and if they do)

    Threaded Messages (117)

  2. So it is official...[ Go to top ]

    BEA has become a follower, not the leader...

    /T
  3. Interesting[ Go to top ]

    This is pretty cool. Why aspectJ and not another aspect framework like what JBoss is doing? Isn't Aspect J purely static? Will this still require the use of a compiler?

    In any case, it is good to see BEA moving this way, looks like AOP is starting to look like the building block for J2EE going forward. I guess those JBoss guys are not really all that crazy after all.
  4. Interesting[ Go to top ]

    Welcome.....to the JBoss way.
  5. BEA as a Technology Leader[ Go to top ]

    I believe that BEA has and continues to be a leader in technology in many ways. Yes, JBoss has made the most public noise about using AOP as a basis for their solution, which makes them a early adopter of AOP technology. But, BEA provides leadership in a number of ways. This technology is available to give early adopters a standard way to integrate with existing systems and a way to explore viable scenarios for AOP in real implementations.

    But, BEA provides leadership in other technologies as well: XMLBeans, Java controls, Java Web Services (JWS), enterprise security framework, EJB CMP implementation, etc. Granted, all of these technologies may not be suitable to all tasks or the most popular for everyone on this board, but they are leaders in their categories.

    Having known Sam for a few years (he regularly kicks my tail at weekly poker), I'm confident in saying that he is one of the most talented engineers I've ever met. His contributions to the early WebLogic Server engine, XML capabilities and (now) AOP have proven his talents in listening to customer momentum and crafting potential solutions. When developing this implementation, Sam consulted customers and a variety of other AOP technologies on the market. What's interesting about this solution is its J2EE-orientation and strong application integration. Not exactly the same approach as other solutions, but nonetheless a solution that should be evaluated.

    I recommend that the community check it out, run through the examples and make a technical analysis as opposed to jumping to any conclusions.

    Tyler Jewell
    Director, BEA
  6. BEA as a Technology Leader[ Go to top ]

    We did a thorough survey of AOP frameworks and despite some very promising ones (I am particularly fond of AspectWerkz), we picked AspectJ because as of today, it is the most powerful framework that contains all the features we need. Nothing is carved in stone right now, we are just publishing this framework to receive some feedback from the community.

    Also, we wanted to focus our time on providing value for our customers so there was no point in writing an AOP framework from scratch.

    --
    Cedric
    http://beust.com/weblog
  7. BEA as a Technology Leader[ Go to top ]

    Nice to see you guys using an eclipse project. Is it possible that we will see use of SWT in BEA products or BEA-supplied plugins for eclipse in the future ?

    --
    Dimitri
  8. SWT and BEA[ Go to top ]

    Hi Dimitri-

    It's been a long time since I've heard from you. To briefly answer your question, BEA WebLogic Workshop is 100% Swing-based. And, I do not believe BEA has any intentions of incorporating SWT or Eclipse elements into any products given the Workshop solution that is currently in place.

    Tyler
  9. BEA as a Technology Leader[ Go to top ]

    \Cedric Beust\
    We did a thorough survey of AOP frameworks and despite some very promising ones (I am particularly fond of AspectWerkz), we picked AspectJ because as of today, it is the most powerful framework that contains all the features we need. Nothing is carved in stone right now, we are just publishing this framework to receive some feedback from the community.
    \Cedirc Beust\

    If you want to go down the AOP route, I personally think this is exactly the right way to go. Define the pointcuts that most J2EE developers would be interested in against your product, use a very well established AOP implementation, and get out of the way :-)

    And I think it's smart to start with AspectJ for now. I've been researching AspectJ on my own recently, and I'm deeply impressed with how much thought the designers gave to AOP in general. Specifically, the modularity concepts built into the language and aggressive promotion of static typing steers developers towards "safe" forms of AOP, and clearly riskier forms of advice for what they are. Plus the static typing eliminates alot of casting :-)

        -Mike
  10. Pointcuts[ Go to top ]

    /mike/
    Define the pointcuts that most J2EE developers would be interested in against your product, use a very well established AOP implementation, and get out of the way :-)
    /mike/

    Actually they can define the pointcuts for general J2EE interfaces, so the framework would work for any J2EE containers. Or did they already make this with the framework?

    Thanx,
    Lofi.
  11. JBoss as a Technology Leader[ Go to top ]

    It is nice to see that BEA is following our leadership and exploring aspects of AOP in the Application Server space. We learned long ago(3 years) that providing various pointcuts to various parts of the app server through our client, server-side, and mbean interceptors are a great way for application developers to fine-tune their applications and for ISVs and tools vendors to integrate more closely in an easier way with our open-source product. It is good to see that BEA finally sees the light.

    We applaud BEA, but we at JBoss already know through years of dealing with our users and integrators that exposing pointcuts works and is far from experimental. JBoss has already begun to take AOP forward in the application server space by providing POJO services that are not defined in the J2EE specification like replicated caching for POJOs as well as transactional objects.

    As Morpheus would say. "Welcome to the 'real' world."

    Regards,
    Bill Burke
    Chief Architect
    JBoss Group, LLC.
  12. Who is following who?[ Go to top ]

    The idea that BEA is following JBoss with this work is laughable. In terms integrating things like classloading preprocessors for making systems like this possible literally goes back to JBoss's infancy. Wily Technology, for instance, was inserting pointcuts and monitorying/management advice into WebLogic and our customers code with our help before JBoss even went 1.0. As it happens, this latest release of AOP functionality uses that same hook. Just because you are now doing arbitrary instrumention in your latest release doesn't mean that people haven't been doing it in WebLogic for some time. Enough history, lets talk about what is going on now.

    Contrary to the intentions of the JBoss AOP framework -- to basically throw J2EE out the window and use a bunch of proprietary non-standard POJO advice -- this framework is built to enable the J2EE developer to take advantage of aspects within that environment without sacrificing portability. Additionally, because it isn't tied to any particular AOP implementation, it has the flexibility to go forward with the state-of-the-art aspect systems without the need to play catchup with those doing the important work in aspect-oriented programming. The release on dev2dev does include AspectJ as its implementation, but you could probably run the JBoss AOP framework if you wanted, all you have to do is implement a trivial interface.

    I expect at some point there will be a standard aspect system for Java or it may even be built into the language. Tying yourself to your own AOP implementation is going to strap you and your users to something that may be deprecated in less than a year.

    You must have chosen the 'blue' pill because your world is pure fantasy.

    Have fun,
    Sam
  13. JBoss as a Technology Leader[ Go to top ]

    Actually I do belong to the jboss fan club.. but that message was hilarious, completely unnecessary and pretty childish. I would appreciate taking marketing to a higher, more professional level if we can't shut it out from these forums.
  14. Childish[ Go to top ]

    Dear Bill Burke, Chief Architect of JBoss Group,

    GROW UP AND QUIT WASTING OUR TIME WITH YOUR CHILDISH BEHAVIOR!

    You do not own J2EE. You did not invent it and your software is free. JBOSS will die a slow death. Please put your cool aid down and relax.

    Who cares about who is following who. I bet you never played sports when you were a kid...true huh!

    Sincerely,

    FED-UP!
  15. Childish???[ Go to top ]

    "JBoss wannabees".

    Of course attacking Bill personally isn't childish, it is grown up stuff.

    We are supposed to buy the latest WL 8.1 crap with integration and portal and all the non-sense? When BEA's own staff follows the JBoss technological lead away from the marketroid bubble. It clearly says where the vision is, in Open Source, and has been for a long time.

    Technically speaking WL lags behind a free implementation? What kind of message does that send to all of you? When JBoss gets certification it will rightfully own the market. JBoss is setting the pace and will for a long time it seems. You may call Bill childish but he showed BEA's technical staff the way.

    Your post is nothing but an empty rant dressed in a personal attack on Bill. That kind of behavior is childish.

    The technology doesn't lie and JBoss leads. End of story, BEA's technical staff is mostly "JBoss wannabees".
  16. Childish???[ Go to top ]

    Lawrence: Your post is nothing but an empty rant dressed in a personal attack on Bill. That kind of behavior is childish.

    Actually, the exchange going between Bill and Sam is pretty good. You see, they have earned the right to goad each other by actually having done some work in this area.

    It's all the fanboys trying to get into the ring that are annoying. Just sit back and let Bill and Sam take care of themselves. They're big boys now. And their conversation is a lot more interesting (and entertaining), too.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  17. From what I have read (limited docs) it appears that WL is merely providing interceptions (pointcuts) and not aspects because aspects do something useful (well I would hope) such as printing out the component stack, ;-).

    The BEA implementation of interceptors just happens to be based on AspectJ's integration into WebLogic's classloader mechanism. Could this have not been achieved by simply providing standard Java Interception interfaces that could eventually find their way into the J2EE specification. What I miss from all of this is context parameters for example security, transactions, persistence, J2EE module.....but if we had that then we probably could not run with previous versions of WL though this has still to be tested by US, ;-).

    If I was to talk to customers I would expect them to ask for better (higher?) abstractions that what is currently being provided. Thats not to say that I NOT AM PLEASED what BEA has done, its going to be great for performance and testing tool vendors. Could this be BEA testing out the implementation for their own forthcoming performance management analysis tooling, ;-(.

    Cedric, I have missed something here but is it possible to move up from the class and understand the J2EE application such as what module(s) are currently on the callstack.

    Anway cheers to BEA. Now lets see can we find real use for Aspects other than logging.


    All the best,


    William Louth
    JDBInsight 2.0 EA Now Open
    www.jinspired.com
  18. Aspects[ Go to top ]

    Hi William,

    From what I have read (limited docs) it appears that WL is merely providing interceptions (pointcuts) and not aspects because aspects do something useful (well I would hope) such as printing out the component stack, ;-)

    We only provide pointcuts in this release because we are trying to gather feedback before we make clear moves in either direction. But we already do have both ideas and implementations of aspects that are most likely going to impress you :-)

    But at this point, we'd rather offer the tool as is and see what our customers do with it.

    As far as BEA is concerned, we are already using both AOP-Java and AOP-J2EE internally. For example, imagine that you are a WLS consultant who's been called on a customer's site because they are suddenly having performance problems. You write a quick aspect to instrument the running application, deploy the aspect, analyze the logs to look for a performance bottleneck and when you're done, you undeploy the aspect and you go home.

    No dumb requirement like "the customer has to be running the latest and greated WLS, even though it's just in alpha right now", or "you have to read and learn a brand new API before you can even start to understand how to write an aspect".

    The BEA implementation of interceptors just happens to be based on AspectJ's integration into WebLogic's classloader mechanism. Could this have not been achieved by simply providing standard Java Interception interfaces that could eventually find their way into the J2EE specification.

    There are a couple of problems with this approach:

    - Interceptors are just a very small subset of pointcuts. The pointcuts offered by AspectJ, and AOP frameworks in general, are much more powerful.

    - The J2EE specification doesn't go far enough for pointcuts to be 100% generic. Note however that it's still very close and a lot of the pointcuts we provided are reusable, but there are also some hairy ones (like EJB.businessMethods()... take a look if you are not faint of heart). But that's the point: we take care of the hairy details, like specifying the pointcuts, so that you can focus on what you know: write aspects in plain Java.

    Cedric, I have missed something here but is it possible to move up from the class and understand the J2EE application such as what module(s) are currently on the callstack.

    There is no limit to what you can do, so the answer is a resounding yes.

    Stay tuned, we are just getting started.

    Anway cheers to BEA. Now lets see can we find real use for Aspects other than logging.

    Exactly! Let's hear from you all!

    --
    Cedric
    http://beust.com/weblog
  19. Aspects[ Go to top ]

    \Cedric Beust\
    There are a couple of problems with this approach:

    - Interceptors are just a very small subset of pointcuts. The pointcuts offered by AspectJ, and AOP frameworks in general, are much more powerful.

    - The J2EE specification doesn't go far enough for pointcuts to be 100% generic. Note however that it's still very close and a lot of the pointcuts we provided are reusable, but there are also some hairy ones (like EJB.businessMethods()... take a look if you are not faint of heart). But that's the point: we take care of the hairy details, like specifying the pointcuts, so that you can focus on what you know: write aspects in plain Java.
    \Cedric Beust\

    Agree, and agree. AspectJ allows you to use either very fine grained and narrow or very coarse grained/broad pointcuts (or a combination thereof) that cover alot more than just method interception. At a high level joinpoints can use wild cards on any aspect of Java typing, and these can be combined with boolean logic along with some very cool designators on types and thread call flow. This means you can create highly selective pointcuts, instead of having to do alot of if-this-if-that checks in your advice.

    Incidentally, most of my (very new) AspectJ knowledge comes from the excellent "Mastering AspectJ" book by Gradecki and Lesiecki. It does a great job of laying the foundation of AspectJ design principals, syntax, and semantics. The only downside of the book is alot of typos which sometimes make it tough to figure out what's going on (typos can be deadly in highly technical texts :-(). Anyway, I recommend it for anyone who wants to really understand what AspectJ is all about, and to understand how AOP can be much more than vanilla interceptors (and how to do AOP in a highly maintainable and functional manner).

        -Mike
  20. Aspects[ Go to top ]

    Incidentally, most of my (very new) AspectJ knowledge comes from the excellent "Mastering AspectJ" book by Gradecki and Lesiecki. It does a great job of laying the foundation of AspectJ design principals, syntax, and semantics. The only downside of the book is alot of typos which sometimes make it tough to figure out what's going on (typos can be deadly in highly technical texts :-(). Anyway, I recommend it for anyone who wants to really understand what AspectJ is all about, and to understand how AOP can be much more than vanilla interceptors (and how to do AOP in a highly maintainable and functional manner).

    >
    > -Mike

    Even better, get the new "AspectJ In Action" by Laddad (currently available from Manning as an e-book). Really explains AspectJ well and goes through many practical examples that you can use. And it has few typos, and the examples work.
  21. Issue with Aspects[ Go to top ]

    Hi Cedric,

    One problem that I currently see (allowing for my lack of AspectJ experience, still waiting for IntelliJ to finish the EA) with what is offered is that in most containers standard J2EE interfaces are implemented by multiple classes and identifying which is the 'One' is quite hard for your typically J2EE customer still trying to understand his own component contracts.

    What do I mean by 'One'? Well take for example a JDBC connection. You have container connection proxies, JDBC driver connections which can be further broken down into general wrappers/pooled and physical. There are many cases of such implementations across various J2EE specifications and implemenations. The Proxy/Decorator pattern is prevalent in container designs.

    Is this really problem? Well, I am sure you know it is, but others might not be aware of this until they attempt it. Take for example the prepartion of a SQL statement. In theory a container could implement this behind its own java.sql.Connection interface which simply looks up some internal map for an existing java.sql.PreparedStatement with the same SQL command. If it is not found the call is delegated to the underlying JDBC driver. If we intercept at the generic interface level when do we know in fact that the prepartion went to the database. This requires callstack analysis and state management. Would you agree or do I really know nothing about AOP/AspectJ, ;-(.

    The solution is probably to make the pointcuts definition more weblogic implementation specific and execution and state aware (callstacks). I am not sure whether AspectJ is that far yet and that expressive.

    Some standardization in interception interfaces could have hidden this from the user and not force AOP programming (AspectJ syntax) on them.

    Getting back to the announcement. Its a good start and I am sure I will be looking at having this technology integrated into my own tooling.

    I look forward to you impressing me, ;-), and maybe I can do likewise by delivering a solution around this technology.

    /** Now off to Amazon for a good AspectJ book */

    Regards,

    William Louth
    Get JDBInsight 2.0 EA Today
    www.jinspired.com
  22. Issue with Aspects[ Go to top ]

    AspectJ does allow you to make yourpoint cuts aware of the dynamic callstack. For example, a pointcut can specify a given method or set of methods _but only if_ another method(s) is on the callstack (or not in the callstack). You can even deal with recursion and detect the first-call to a recursive call (and distinguish first-call arguments from the recursive ones). There are some limitations, but AspectJ pointcuts are alot more expressive than many people realize.

    As for interceptors vs. AspectJ - yes, an interceptor interface would allow you to stay pure Java, but that's about the only benefit I could see (for both BEA and customers). _If_ you can get past the idea of using AspectJ (admittedly a big if), this approach opens up many possibilities in general, is highly reusable, and can easily be extended to cover new stuff. An interceptor design on the other hand would require an awful lot of work and be somewhat fragile, and would be IMHO be less likely to survive refactorings of code over time or be extensible to new stuff coming down the pike.

         -Mike
  23. Issue with Aspects[ Go to top ]

    Hello,


    > One problem that I currently see (allowing for my lack of AspectJ experience, still waiting for IntelliJ to finish the EA) with what is offered is that in most containers standard J2EE interfaces are implemented by multiple classes and identifying which is the 'One' is quite hard for your typically J2EE customer still trying to understand his own component contracts.
    >
    > What do I mean by 'One'? Well take for example a JDBC connection. You have

    I can't vouch for WL but in JB, just instrument your pojo class, in this case

    com.louth.william.myDriver

    You need pojo interceptors.

    Let's wait a bit and this discussion will soon reach the instance instrumentation question where the notion of "the one" reaches "what instance" :))) then it gets fun as we will go to the tools.

    marcf
  24. Aspects[ Go to top ]

    Anway cheers to BEA. Now lets see can we find real use for Aspects other than logging.

    >
    > Exactly! Let's hear from you all!

    Ok I will start. Man we need to do a better job at posting stuff here. Since JBoss 2.x we use interception for remoteness, security, transaction, persistence, cache client and server side for EJBs.

    In JBoss4.x we use the same for POJO's and add some cool features with it (done or in development) generalized caching with automate replication and fine grained (we monitor the get/set or CRUD equivalents) ACID where we make a web layer object acid for example, or one way invocations (corba equiv) etc etc. Logging is so boring.

    AOP itself is great but what is interesting are the aspects built on top and middleware we build out of them. AOP for the beauty of it isn't really relevant to system designers. AOP for systems is nirvana though.

    I was in RIO for the middleware 2003 research conference to give the keynote speech and got to see the latest research in middleware AOP. Crazy stuff, dynamic AOP of POJO's for robot control all kinds of stuff. The applications are interesting as middleware aspects are AOP's killer app.

    marcf
    >
    > --
    > Cedric
    > http://beust.com/weblog
  25. Aspects[ Go to top ]

    Now lets see can we find real use for Aspects other than logging


    I don't know a great deal about Aspects but when I see statements like this it worries me. Shouldn't new technologies (or ways of applying them) be introduced to solve real problems not the other way round ? Don't we already have enough complexity in J2EE already without our technical boffins forcing yet more API's on us ? How about improving or *getting rid of* some of the existing J2EE baggage first ?

    Cart before the horse ?
  26. Aspects[ Go to top ]

    Now lets see can we find real use for Aspects other than logging

    >
    > I don't know a great deal about Aspects but when I see statements like this it worries me. Shouldn't new technologies (or ways of applying them) be introduced to solve real problems not the other way round ? Don't we already have enough complexity in J2EE already without our technical boffins forcing yet more API's on us ? How about improving or *getting rid of* some of the existing J2EE baggage first ?
    >
    > Cart before the horse ?

    I think you just need to read more about what aspects are and the potential impact they have on programming. Think about the difference between procedural programming and OO and you'll start to get the idea.

    Besides, it sounds like BEA did some of the hard work for you so implementing your own aspects will be easy if you use their templates.

    BTW: Seriously, what packages or classes would you suggest they cut out of J2EE? Messaging? Web Services? EJB? If J2EE is too complex you should look into using some of the higher level tools, like BEA Workshop, that hide a lot of the gory details.
  27. Aspects[ Go to top ]

    Now lets see can we find real use for Aspects other than logging

    > >
    > > I don't know a great deal about Aspects but when I see statements like this it worries me. Shouldn't new technologies (or ways of applying them) be introduced to solve real problems not the other way round ? Don't we already have enough complexity in J2EE already without our technical boffins forcing yet more API's on us ? How about improving or *getting rid of* some of the existing J2EE baggage first ?
    > >
    > > Cart before the horse ?
    >
    > I think you just need to read more about what aspects are and the potential impact they have on programming. Think about the difference between procedural programming and OO and you'll start to get the idea.
    >
    > Besides, it sounds like BEA did some of the hard work for you so implementing your own aspects will be easy if you use their templates.
    >
    > BTW: Seriously, what packages or classes would you suggest they cut out of J2EE? Messaging? Web Services? EJB? If J2EE is too complex you should look into using some of the higher level tools, like BEA Workshop, that hide a lot of the gory details.

    Thanks I'm beginning to see where this AOP stuff is coming from. Wouldn't really want to answer your question as its not directly related to this thread and its been argued before (to death) and argued by people more capable than my good self. But reducing the EJB spec by about two thirds and re-naming it *EJB Lite* is probably where I would start...
  28. Aspect's Logging[ Go to top ]

    Now lets see can we find real use for Aspects other than logging


    >>I don't know a great deal about Aspects but when I see statements like this >>it worries me. Shouldn't new technologies (or ways of applying them) be >>introduced to solve real problems not the other way round ?

    I was a bit harsh in that 'logging' statement. We do need to see more real world usage to determine best practices (its all about the application of the technology to problems that do exist but are being solved in a different manner). I am sure there is a Bitter AOP book already in the works, ;-).

    Marc, you are right, there is a need to be more selective in the applying of aspects(pointcuts/interceptions) such as at the instance. I had already indicated this in a previous post where I mentioned modules. There is certainly a requirement out in the field to apply WL J2EE pointcuts for particular application modules. Context awareness is where eventually we will need to go. I would like to see more work on the context API.

    AOP should lead to the speedier adoption and creation of Complex Event Processing (CEP) (read 'The Power of Events' Book) systems.

    All the best,

    William Louth
    JDBInsight 2.0 EAP
    www.jinspired.com
  29. Aspect's Logging[ Go to top ]

    William,

    Aha, seems like you're reading the same book I'm reading (i.e. Complex Event Processing).

    Yes, instance based pointcuts or pointcuts based on context are extremely important. AspectJ doesn't support this yet, the buzzword used for this kind of aspects is "fluid AOP".

    See the CaesarJ stuff for use cases.

    Carlos E. Perez
  30. Disadvantage of AspectJ[ Go to top ]

    <cedric>
    There is no limit to what you can do, so the answer is a resounding yes.
    </cedric>

    For me personally, one of the most useful aspects of Dynamic AOP (be it JBoss AOP, AspectWerkz or some other framework) over AspectJ is that you can dynamically 'instrument' POJOs (Plain Old Java Objects). Let me explain.

    Requirement: I want to add POJOs into a cache and dynamically replicate all changes. The way this is currently done (e.g. in HTTP session replication) is to replicate on setAttribute(). Whenever you change an object, you have to call setAttribute() and this will serialize the entire object and send it across the wire.

    With Dynamic AOP you can dynamically attach interceptors to all 'parts' of the POJO. By 'parts' I mean other complex objects reachable from the POJO, essentially the transitive closure over the object (graph).
    The interceptors can keep track of the fields that have changed, and we don't need to send the entire POJO's state across the wire, just the changed fields.

    Replication is just one aspect, the same technique can be used for persistence as well.

    This is something that AspectJ cannot do. Correct me if I'm wrong.

    Bela
  31. ineficient replication[ Go to top ]

    Replicating on operation by operation
    basis is about as ineficient as you can
    get. Certainly you can do it, but why
    you would do it is a different story.
  32. ineficient replication[ Go to top ]

    I didn't say I replicate after each operation. Typically you would replicate at TX commit time.
    Bela
  33. bela ban said:
    > With Dynamic AOP you can dynamically attach interceptors to all
    > 'parts' of the POJO. By 'parts' I mean other complex objects
    > reachable from the POJO, essentially the transitive closure
    > over the object (graph).
    >
    > The interceptors can keep track of the fields that have changed,
    > and we don't need to send the entire POJO's state across the wire,
    > just the changed fields.
    >
    > This is something that AspectJ cannot do. Correct me if I'm wrong.
    >

    You are partly wrong. Your statement

      with dynamic AOP you can dynamically attach interceptors
      to all 'parts' of the POJO.

    mixes two different issues, namely
      - whether aspect deployment is dynamic,
      - and what is the granularity of join points in the AOP tool

    AspectJ has join point granularity that is finer that JBoss (last
    time I checked JBoss), so it can attach advice to all the points
    that JBoss can. But AspectJ's semantic model is static, aspects
    happen against classes, not individual objects. Although note
    that AspectJ now weaves on jar files, and will sooner weave in
    a loader, so its much more flexible than it used to be.

    The issue of whether dynamic AOP is worth the cost is, IMHO, still
    very much open. The performance costs are significant, not so much
    for the reflective call, but for all the casts it introduces. On
    the other hand, the flexibility is quite powerful. And people like
    Mira Mezini are working on adding dynamic deployment to AspectJ
    without breaking the static type checking. That looks quite promising.

    In addition, for many aspects that you want to deploy dynamically,
    the common AspectJ idiom of having a static aspect that maintains a
    hashedSet of objects it is deployed on results in clear, fast,
    type-safe code.
  34. Although the aspect system shipping on dev2dev uses AspectJ it still weaves the aspects at runtime whenever a class is loaded. So just because AspectJ is restricted to applying aspects at compile time, the system is not since the weaving occurs at runtime, only the compilation of aspects and advice is done before deployment. In fact my normal demo of the system is to:

    1) Bring up a fresh server with the aspect system enabled.
    2) Create a new webapp using Builder and deploy it to the server.
    3) Write a JSP or two and use them to show that the application works.
    4) Write an aspect against the JSP code or use the sample J2EE aspects/advice included with the distribution.
    5) Put the sample aspect jar in the WEB-INF/lib directory of the webapp.
    6) Redeploy the webapp and show how the advice gives you a component call stack or some other interesting piece of information.
    7) Delete the sample aspect jar and redeploy show how the advice is no longer present.

    Its pretty straightforward and will work with any aspect system that takes classfile bytes and gives you back classfile bytes.

    Sam
  35. Okay Gregor,
    let's do an example. Can you 'do' the following in AspectJ ?

    (pseudo code)

    Person
      name: string
      age: int
      addr: Address
      hobbies: collection

    Address
      city: string
       zip: int


    Person p=new Person("Bela", 38, new Address("San Jose, 95124), {"Triathlon", "Running", "etc"});

    TX-start
    p.setAge(p.getAge()+1);
    p.name="bla";
    p.getAddress().setZip(95134);
    TX-commit

    At this point, I want to replicate p.age, p.name, p.add.zip in one message. (Note that here I could also persist p into a DB).

    This is a trivial example, but if you have large objects, you can reduce the overhead of serialization and network traffic.

    Dynamic AOP in JBoss (check out TreeCacheAop for an example) does this by adding an interceptor to p and one to p.addr, so by using a combination of reflection and interceptors it knows how to recursively traverse the object graph and it also knows when fields have changed. At TX commit time, modified fields are (a) written back to the POJO and (b) replicated to other cache instances.

    How can you do this in AspectJ without preprocessing Person offline ?

    Again, my knowledge of AspectJ is a bit dated, so maybe you *can* do this.
    Bela
  36. Okay Gregor,

    > let's do an example. Can you 'do' the following in AspectJ ?
    > <snip>
    > How can you do this in AspectJ without preprocessing Person offline ?

    The point of my message wasn't to say that AspectJ was dynamic. It was to say that you had (probably accidentally) mixed the issue of granularity of join points and whether there is dynamic aspect deployment together.

    But the AspectJ semantics is definitely static, so it will require "off-line" processing of the code. Although, as Sam already pointed out [1], that doesn't have to be at compile time, it can be at the time the class is loaded.

    So that's what I meant by "partly wrong" -- mixing together of join point granularity and the static/dynamic issue isn't right, but you are right that AspectJ is static. But, its not as static as it used to be, and doesn't require a "compile" with sources of the crosscut classes.


    [1] (http://www.theserverside.com/home/thread.jsp?thread_id=20514#90237)
  37. Control flow aspects[ Go to top ]

    Actually, this type of thing seems well suited to AspectJ's percflow aspects. Consider the following:

    import java.util.WeakHashMap;

    public abstract aspect TrackChanges percflow(start()) {
        abstract pointcut start();
        
        WeakHashMap cache = new WeakHashMap();
        
        after(): cflow(start()) && set(* *.*) {
            Object value = thisJoinPoint.getArgs()[0];
            cache.put(thisJoinPoint.getSignature(), value);
        }
        
        after(): start() {
            // replicate as necessary
            // ...
        }
    }

    Here we have an aspect that builds a cache of all state changes that occur within the execution of a pointcut (like Servlet doGet() for example). I'm tracking the value here, but you could just as easily keep track of the list of impacted target objects. percflow ensures that the cache is local to the control flow execution.

    Assuming you have an efficient way to intersect this list of modified objects with an object graph that requires replication (like a session), you could replicate a delta instead of the full object graph.

    So, compile or load time discussion aside, this doesn't really strike me as a limitation of AspectJ. The technique to implement it efficiently is probably quite different than would be required with JBoss AOP, but that is to be expected.

    Cheers,

    Merrick
  38. Disadvantage of AspectJ[ Go to top ]

    \Bela Ban\
    With Dynamic AOP you can dynamically attach interceptors to all 'parts' of the POJO. By 'parts' I mean other complex objects reachable from the POJO, essentially the transitive closure over the object (graph).
    The interceptors can keep track of the fields that have changed, and we don't need to send the entire POJO's state across the wire, just the changed fields.
    \Bela Ban\

    This is far beyond my limited AspectJ knowledge, so see Gregor's response to AspectJ's abilities in this area.

    AOP implementation abilities aside, why would you want to do this in the normal course of business? I can think of some extreme examples where objects may involve a large amount of data, but in most cases the cost of tracking changes is higher than just sending the graph. Further, it's generally smarter to limit the size of the graph to begin with and avoid this problem altogether.

    This IMHO is the problem with the magically-aspectize-POJO-approach to the world. You can't easily constrain the POJOs, and as a result your aspects have to deal with all sorts of issues that a more explicit implementation can safely ignore. Since the POJO can do any POJO thing it wants, and you may have a "container" that's trying to deal with any POJO but still do it fast, your container ends up jumping through hoops to make an elephant dance.

    I personally prefer AspectJ's very strong emphasis on strong typing and language constructs to help enforce modularity, seperation of concerns, and promoting usability through things like abstract aspects. Plus a heavy concern about performance costs. There's clearly alot of magic you can do with AspectJ to instrument "foreign" classes to do things they never were intended for, but it's not the main thrust - the main thrust isn't magic, or less finger typing, it's making it easier to seperate concerns in a managable and scalable manner.

        -Mike
  39. Disadvantage of AspectJ[ Go to top ]

    AOP implementation abilities aside, why would you want to do this in the normal

    > course of business? I can think of some extreme examples where objects may
    > involve a large amount of data, but in most cases the cost of tracking changes is
    > higher than just sending the graph. Further, it's generally smarter to limit the size of
    > the graph to begin with and avoid this problem altogether.


    You cannot control what POJOs users create.

    The cost of tracking may be significanly lower than sending the whole graph (serialization, network bandwidth).

    Again, think of HTTP sessions: you want to (a) only replicate modified fields and (b) the user doesn't need to hace to call setAttribute() every time some small field has changed. Also, we can replicate at TX commit time. The latter is not relevant for HTTP sessions but you get the point.


    > This IMHO is the problem with the magically-aspectize-POJO-approach to the
    > world. You can't easily constrain the POJOs, and as a result your aspects have to
    > deal with all sorts of issues that a more explicit implementation can safely ignore.

    Yes - same with object DBs, some 10 years ago


    > Since the POJO can do any POJO thing it wants, and you may have a "container"
    > that's trying to deal with any POJO but still do it fast, your container ends up
    > jumping through hoops to make an elephant dance.


    No, we don't do everything for you. Check out TreeCacheAop. I think it is a useful example of Dynamic AOP. Of course, I don't propagate this as a solution to all problems, but I believe it is an elegant solution for these sorts of issues.

    Bela
  40. Disadvantage of AspectJ[ Go to top ]

    With Dynamic AOP you can dynamically attach interceptors to all 'parts' of the POJO. By 'parts' I mean other complex objects reachable from the POJO, essentially the transitive closure over the object (graph). The interceptors can keep track of the fields that have changed, and we don't need to send the entire POJO's state across the wire, just the changed fields.

    I'm not sure I follow this completely. If I have a java.util.Date d, and I put d into a field of some object c into a field of some object b into a field of some object a and put a into the session, and I later make a change to date value held in d (since Date is mutable), that change will be replicated? (Note that I haven't called getAttribute or anything like that ... I just held a reference to d which is reachable from a.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  41. Disadvantage of AspectJ[ Go to top ]

    Cameron,

    is there some message hidden in your post ? :-) The highlighted chars don't make up a msg...

    > I'm not sure I follow this completely. If I have a java.util.Date d, and I put d into a field of some object c into a field of some object b into a field of some object a and put a into the session, and I later make a change to date value held in d (since Date is mutable), that change will be replicated? (Note that I haven't called getAttribute or anything like that ... I just held a reference to d which is reachable from a.)

    Just the change in 'd' if your graph was already previously replicated. Otherwise the entire graph (if you created it).
    Bela
  42. Disadvantage of AspectJ[ Go to top ]

    Hi Bela,

    Sorry my question wasn't clear. The highlighted letters were variable names (or some such logical ref for the point of asking the question.)

    What I am trying to figure out is whether you are instrumenting the class, or somehow trying to "instrument" (definitely in quotes now) the object itself, or if you are creating a sub-class dynamically to wrap the ones you are interested in, or what ....

    That's why I picked a java.* class for the example, kept a ref to it, put something referring to it into the session, and asked what would happen if I mutated the original object after doing so.

    And I don't know the answer, so I am not trying to trick you or something ;-) ... I'm curious. (I hope no one else minds if the thread discusses technical aspects of AOP, as opposed to arguing who did what first or how crazy someone is.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  43. AOP Technical implementation[ Go to top ]

    I can't speak for anyone else, but I'd sure be interested in know how this works. Using your example, not all Date instances would be/should be replicable, so it would seem that JBoss weaver finds when "a"'s instance variables are set, and then dynamically sets a join point on the relevant instance variable's object (and somehow reflectively gathers up "d"'s members via reflection for tracking in a recursive manner to what it did with "a").

    Alternatively, I suppose all Date objects could be intercepted and checked if they're owned by "a" (or other objects of that class), but that would seem unacceptably slow.

    In any case, the details of how it's actually done beyond my wild speculations would be interesting.

        -Mike
  44. Cameron's question[ Go to top ]

    An excellent example/question indeed. In my opinion however, whatever the actual algorithm (if any at all) the now unfashionable graph scan (or sending the whole graph optionally, etc.) on tx boundaries would work just fine, would be more clear for developer and would have seemingly lower runtime overhead.

    Just my 2 cents,
    Nikita Ivanov.
    Fitech Labs.
  45. Cameron's question[ Go to top ]

    There's certainly an undeniable "coolness" factor here, in the sense of it feels incredibly cool to either delta an object, or mark it partial-dirty with a list of fields, without any real work. But if you leave coolness aside for a moment - is it the right thing to do? Does it make sense in a number of application contexts? Do the checks and balances favor this solution over another? And does it plain work well when applied to arbitrary POJOs that are unconstrained?

    What bothers me most about this sort of approach is that there's a strong emphasis on the POJO writer to have zero knowledge of the aspects around it, and that said writer really is assumed to be unconstrained. In my own experience, just a touch of constraint in the right places can result in startling reusability, ease of maintenace, and above all performance. When you KISS and narrow the range of possibilities, you can take aggressive advantage of that narrowness (and sometimes only a teeny bit of narrowing).

    Many may discount this, but to me every approach/strategy/API/implementation/system have obvious emphasises, and these emphasises very strongly color the use of the system. You can work around or against it, but you're constantly being pushed by the prejudices and assumptions that are built into whatever you're using. Follow the path and things are easy, try to beat your own path and you're going to have to fight constant pressure.

    I like AspectJ's flavor and emphasis because it's ultimately not about instrumenting POJOs in the dark. The emphasis is on encapsulation, modularization, and avoiding some of the darker corners of AOP in Java through explicit language constructs (but leaving in backdoor access when you really need it :-). Alot of the AspectJ books emphasize building applications from the ground-up using AOP, and deciding what to put in "primary concern" plain old Java classes and what to put in seperate aspects based on concerns. Tricks like intercepting all Swing calls, or logging every method, or aggressively mangling an existing POJO are discussed in little side bars but are _not_ the main idea - system design and development over the long haul are.

    The emphasis on JBoss is entirely different, and it shows at every level. It was my first look into AOP, and it turned me off big time because it strikes me not at elegant design and engineering, but a neato-cool hacker tool kit that will result in tortuous maintenance cycles. AspectJ is a deeply thought out runtime and language that obviously came from very serious and damned competent language and system designers who are constantly striving to strike many balances and compromises. JBoss AOP just doesn't have that feel - it may be just me, but it feels like something cobbled together here and there over weekends. I know I can sell AspectJ in my organization, despite the "new-language" negative conotations, because its depth and the professionalism behind it are self-evident. I couldn't do that with JBoss AOP - it's not a comprehensive, cohesive whole, it's a fairly simple runtime bolted onto a running JVM.

    Anyway, I've yet to hear _why_ you'd want to do the sorts of things with POJOs that the JBoss group is advocating. "Why" as in solid stats and analysis of why it's better, not "Why" as in it's-so-freakin'-cool, or we're light-years-behind-dinosaur-EJBs. As Gregor has said elsewhere, why build so many competing partial-AOP systems and not just use and extend AspectJ?

        -Mike
  46. AOP Technical implementation[ Go to top ]

    No, all I said was that we make instances of Date 'interceptable'. We only add interceptors on demand, e.g. when inserting them into the cache. Date objects you don't insert into the cache will not have interceptors, thus won't be replicated.

    E.g. (in pseudo-code):

    Person p;

    Chain l=((Advisable)p).getInterceptorChain();
    if(!l.containsInterceptor(this)) {l.add(this);}
    //this is an interceptor

    This is actually implemented in TreeCacheAop, so (if you're interested) you can check this out from the JBoss CVS.

    Bela
  47. Disadvantage of AspectJ[ Go to top ]

    What I am trying to figure out is whether you are instrumenting the class, or somehow

    > trying to "instrument" (definitely in quotes now) the object itself, or if you are creating
    > a sub-class dynamically to wrap the ones you are interested in, or what ....

    No, instrumentation is always at the class level. If the class is already loaded, you'd have to reload it in a different classloader, at least in JBoss. Also note that there are issues with system classes...

     
    > That's why I picked a java.* class for the example, kept a ref to it, put something
    > referring to it into the session, and asked what would happen if I mutated the original
    > object after doing so.

    You should be able to instrument Date, unless it is already loaded.

    The standalone AOP lib that Bill put out on the JBoss site is pretty neat.

    Bela
  48. Disadvantage of AspectJ[ Go to top ]

    Hi Bela,

    >
    > Sorry my question wasn't clear. The highlighted letters were variable names (or some such logical ref for the point of asking the question.)
    >
    > What I am trying to figure out is whether you are instrumenting the class, or somehow trying to "instrument" (definitely in quotes now) the object itself, or if you are creating a sub-class dynamically to wrap the ones you are interested in, or what ....
    >
    > That's why I picked a java.* class for the example, kept a ref to it, put something referring to it into the session, and asked what would happen if I mutated the original object after doing so.
    >
    > And I don't know the answer, so I am not trying to trick you or something ;-) ... I'm curious. (I hope no one else minds if the thread discusses technical aspects of AOP, as opposed to arguing who did what first or how crazy someone is.)
    >
    > Peace,
    >
    > Cameron Purdy

    We would prefer design discussions on JBoss on the JBoss developer forum. I have answered your post here:

    http://www.jboss.org/thread.jsp?nav=false&forum=151&thread=36943

    If we can solve the issues of POJO caching/aciditiy/replication transparently through AOP, then we really and truly have something powerful. This is the end goal.

    Bill
  49. Bill, what you've posted flatly contradicts what Bella posted (and in fact I have a strong feeling of Deja Vu from the P2P JMS thread where three people gave three very different answers on how it would work in the future). So will the real implementation please stand up? :-)

    If in fact you are only including included classes that are tagged in some manner as you stated, then you can easily do the same in AspectJ.

    \Bill Burke\
    If we can solve the issues of POJO caching/aciditiy/replication transparently through AOP, then we really and truly have something powerful. This is the end goal.
    \Bill Burke\

    I think its a good idea to do it transparently to the POJO - but not transparently to the developer (outside of some tagging). For it to work well in practice in a wide variety of situations you _do_ need cooperation from some application code, not in the POJO but elsewhere.

        -Mike
  50. <mike>
    If in fact you are only including included classes that are tagged in some manner as you stated, then you can easily do the same in AspectJ.
    </mike>

    I don't know the source code for the JBoss AOP but I get the feeling that you must tag (aspectize?) the class for a JBoss Aspect (manager like role) which then forwards interceptions onto dynamic registered listeners. The JBoss aspect simply acts as a forwarding>dispatcher - it is this which makes it dynamic. Is the dynamicism in the array list? I am completely off the ball here.



    William Louth
    Get JDBInsight 2.0 EA 1
    JInspired
  51. If in fact you are only including included classes that are tagged in some manner as you stated, then you can easily do the same in AspectJ.

    >

    The only tagging that occurs is "I want this class instrumented so that interceptions can be added later on at runtime for fields, constructors, and/or methods either at the class level or instance level." That is the only tagging that occurs. This is there because, even though the performance hit is minimal, you don't want to instrument every class loaded for that reason.

    If a class is tagged and instrumented in this way, class-level aspects can be hot-deployed or undeployed, and things like the cache can add advices on a per instance level.

    I am looking into things like HotSwap, but I don't know yet what the effects of running in debug mode under JPDI are yet with an app-server. Of course, you could always redeploy the JAR the class is deployed in, but this isn't a complete solution all the time.



    > \Bill Burke\
    > If we can solve the issues of POJO caching/aciditiy/replication transparently through AOP, then we really and truly have something powerful. This is the end goal.
    > \Bill Burke\
    >
    > I think its a good idea to do it transparently to the POJO - but not transparently to the developer (outside of some tagging). For it to work well in practice in a wide variety of situations you _do_ need cooperation from some application code, not in the POJO but elsewhere.
    >

    Obviously. The developer knows the POJO will be transactional, because she inserts it into a transactional cache.

    Bill
  52. If the developer knows the Java object is going to be transactional, then what's the point? Why even call it a POJO. It's a transactional object at this point and there are existing and correct ways to do transactional objects. EJB provides one way; Arjuna Transactional Objects is another; some CLOS-style dynamic proxy that implements transactional semantics will work well. The idea behind using AOP approach is that the object is merrily created with a state of "obliviousness" with respect to the aspects that are being applied. And for transactions, as you've just pointed out, that really doesn't work.

    Greg
  53. \Bill Burke\
    Obviously. The developer knows the POJO will be transactional, because she inserts it into a transactional cache.
    \Bill Burke\

    This isn't what I meant, sorry if I was unclear. Ideally the POJO should be written to your domain model (or, more generally and accurately, to your primary concerns), but you don't want it aware of secondary concerns like transactionality etc.

    However - just because the POJO isn't aware of things like transactions doesn't mean that you don't want/need code that is transactional aware (and sticking something into transactional cache doesn't count :-). Often, application code needs to be written to customize the transctional aspects of a given POJO, _but done outside of the POJO_. That is, the containers defaults just don't do everything you need.

        -Mike
  54. Aspects[ Go to top ]

    For example, imagine that you are a WLS consultant who's been called on a customer's site because they are suddenly having performance problems. You write a quick aspect to instrument the running application, deploy the aspect, analyze the logs to look for a performance bottleneck and when you're done, you undeploy the aspect and you go home.

    Why this WLS consultant didn't use WilyTech product which instruments bytecode using classloading hook on the fly ?

    --
    Dimitri
  55. WilyTech[ Go to top ]

    Hi Dimitri,

    1) He has previously used WilyTech and feels that the world has moved on from Green and Red Circles (not particular rendered well) for information visualization, ;-)? He might also be color blind?
    2) He could not afford the time and expense in setting up the management server?
    3) The aspects defined could be better tailored to those particular parts of the application he wants to tune?
    4) He loves creating log files and using his favourite unix tools to generate reports?

    Seriously, merely capturing and recording interceptions is less than half the battle. The real problem facing this consultant is deriving information from vast amounts of log entries. Anybody can log or instrument an application the hard part is being able to make sense out of enormous amount of data - graphical excellence.

    All the best,

    William Louth
    Get JDBInsight 2.0 EA
    www.jinspired.com
  56. WilyTech Correction[ Go to top ]

    Anybody can log or instrument an application the hard part is being able to

    >> make sense out of enormous amount of data - graphical excellence

    I meant to say that anyBEAbody CAN NOW log or instrument an J2EE application.

    All the best,

    William Louth
    Get JDBInsight 2.0 EA
    www.jinspired.com
  57. Childish???[ Go to top ]

    "The technology doesn't lie and JBoss leads."

    Yes, JBoss was first to officially launch/market AOP integrated with a J2EE server. That AOP worked with J2EE before (e.g. using Javassist or aspectwerkz) was silently ignored by the jboss folks. That the AOP framework launched by JBoss was not really say "top-notch" was also silently ignored. But if you are a marketing guy, you just say JBoss leads. At least AOP-wise, I wouldn't say JBoss leads without blushing. But I guess everyone can believe what they want to believe. It's healthy and doesn't hurt. Just say it ten times in a row: We are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best. Did it work? Good. You just became a leader.
  58. Childish???[ Go to top ]

    "The technology doesn't lie and JBoss leads."

    >
    > Yes, JBoss was first to officially launch/market AOP integrated with a J2EE server. That AOP worked with J2EE before (e.g. using Javassist or aspectwerkz) was silently ignored by the jboss folks. That the AOP framework launched by JBoss was not really say "top-notch" was also silently ignored. But if you are a marketing guy, you just say JBoss leads. At least AOP-wise, I wouldn't say JBoss leads without blushing. But I guess everyone can believe what they want to believe. It's healthy and doesn't hurt. Just say it ten times in a row: We are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best, we are the best. Did it work? Good. You just became a leader.

    Man, it is called marketing, and has been done since the stone age.
  59. Childish???[ Go to top ]

    That AOP worked with J2EE before (e.g. using Javassist ... )


    AOP using Javassist? Huh?! Getting rather low level are we? Javassist is a byte code manipulation library.

    Maybe you need to calm down a notch.

    /T
  60. Childish???[ Go to top ]

    Yeah, you count your beans somewhere else. What d'you think jAdvise is using? Maybe you need to be wear Hanis crown again.
  61. Childish???[ Go to top ]

    Umm, Bob.. what do you think JBossAOP is using?

    /T
  62. Childish???[ Go to top ]

    Uhm, Thomas ... javassist maybe? So what were you trying to say in your original post?
  63. Childish???[ Go to top ]

    So what were you trying to say in your original post?


    You said: "AOP worked with J2EE before (e.g. using Javassist or aspectwerkz)"

    Nobody does AOP with J2EE by integrating Javassist library alone, you need to build an AOP framework to do it. Which is what JBossAOP is. They did not silently ignore javassist -- as you claimed -- in fact they embraced it. And the fact that javassist exists certainly does not mean AOP exists for J2EE.

    /T
  64. Childish???[ Go to top ]

    Ok, that's right. Maybe I should have written jAdvise. You are so clever. Congratualtions.
  65. Childish???[ Go to top ]

    What is so wrong with following the free implementation? IMHO, that should be the luxury entitled to those working on the free implementations, i.e. that they have the freedom to experiment and forge new ground.
  66. AOP[ Go to top ]

    <quote>
    BEA has released a WebLogic Aspect Framework. This framework is based on AspectJ and is made of a set of predefined pointcuts that WebLogic users can simply reuse and write aspects for.
    </quote>

    <tyler>
    I believe that BEA has and continues to be a leader in technology in many ways. Yes, JBoss has made the most public noise about using AOP as a basis for their solution, which makes them a early adopter of AOP technology. But, BEA provides leadership in a number of ways. This technology is available to give early adopters a standard way to integrate with existing systems and a way to explore viable scenarios for AOP in real implementations.
    </tyler>

    It would be very nice from BEA if they offer those predefined pointcuts to any J2EE containers. I think, it's possible to keep those pointcuts J2EE implementation independent, as you can add those pointcuts to the J2EE API (implementation independent). In this way:
    - We can install the framework at any J2EE containers. All predefined pointcuts are standardized (just like the example above: before() : EntityEJB.findByPrimaryKey()).
    - We can write the aspects in a standardized AspectJ language.

    Or maybe this is already possible? Could someone give me a clue? Thanx!

    Lofi.
    http://www.openuss.org
  67. JBoss is the real thing[ Go to top ]

    Is this official? I can't imagine BEA marketing would approve of it. It has a big splashy screen that screams "JBoss wannabees" on it.
  68. AOP...[ Go to top ]

    I don't really understand the problem with AOP, JBoss, WebLogic, etc. It's just normal to use AspectJ or any other AOP frameworks in any applications (J2EE container, your J2EE applications or even your "Hello World" applications). You can do this since the first time AspectJ is delivered to the market.

    Anyway, a good choice for WebLogic to take AspectJ. At least AspectJ has its own standard language and very flexible. I hope that someday we'll get the AOP alliance standard API for the rest of the AOP frameworks. So, at the end we'll have:
    - AspectJ with its own aspect language and
    - AOP Alliance API for the rest of the frameworks

    which make AOP exchangeable.

    Lofi.
    http://www.openuss.org
  69. aop != interception ? :)
  70. AOP for All[ Go to top ]

    AOP has been around for a long time (perhaps not in Java, but the principle has). The only difference now is that the software development community have no woken up to it in mass. Many developers (including me) believe it will make a huge impact on software development, perhaps not as much as OOP but its right up there.

    I had a quick look at BEA's framework, its pretty cool! At this stage in the game the more people who explore the area the better in the long run. I am always surprised at this "we already have this so why make that", yeah I guess we already have bread in the shops, why open a bakery.
  71. Non Sun or JCP? Schocked![ Go to top ]

    Without Sun JCP spec., we got something usefull.

    I am SHOCKED, SHOCKED that we can get things that Java Community needs without Sun’s help.
    .V
  72. Non Sun or JCP? Schocked![ Go to top ]

    I'm glad that AOP is being research without the JCP right now. The AOP alliance isn't waiting for Sun. AOP will be/is too important to let Sun mess it up.

    Steve
  73. Thank you BEA[ Go to top ]

    Personally, I am kind of happy to see BEA get in the fray. I kind of applaud them to being ballsy enough to try AOP. And the fact that BEA is there will validate AOP to the enterprise markets which can only speed up everyone's adoption.

    On the claims of who is first, it is not important and yet it is important. JBoss extends the J2EE specification and again seeing BEA push the same marketing is good for us as we are not alone or crazy anymore when we talk to analysts and press.

    I see it more as a case of collective innovation beyond the spec. And I believe it is in fact a JSR at the J2SE level (it is a VM feature when you think about it) not necessarily at the J2EE level. But that is another topic.

    As far as the right way to do AOP, AOP == Interception + query language to apply pointcuts. Meaning it needs to live in the VM in java.

    The rest is a lot of hot air if you ask me :). So yes doing JBoss 2.x style interception on client and server is the real thing (pointcuts are the methods) and no doing classloading instrumentation stuff in WL doesn't qualify. Really be serious if you want to discuss about it.

    The fact that it is compilation based is a problem inherent to WL's design in my mind and they will have to go through hoops to achieve no compilation. But hey we have been there for a while and that has been one "innovation" that BEA hasn't copied yet. As an aside dynamic AOP is extremelly important with applications like caching, monitoring, and embedded systems instrumentation and one of the reasons we pushed so hard for it in JBoss. You can't get that with AspectJ.

    Anyway, I am glad this is public, we can use a bit of competition.
  74. Dynamic vs Compilation[ Go to top ]

    Correct me if I'm wrong, but doesn't dynamic AOP impact performance since compile-time intercepts are resolved and added at compile time, whereas dynamic AOP is forced to alter the byte code stream during class loading? Just curious, I'm still trying to understand the whole AOP thing, thanks

    Raffi
  75. Dynamic vs Compilation[ Go to top ]

    Raffi: Correct me if I'm wrong, but doesn't dynamic AOP impact performance since compile-time intercepts are resolved and added at compile time, whereas dynamic AOP is forced to alter the byte code stream during class loading?

    If dynamic is done by byte-code manipulation, then there is no runtime impact vis-a-vis compile-time, because the resulting classes are theoretically the same.

    If dynamic is done by other means, then there can be a runtime impact. Rickard covered this in his blog regarding the JBoss approach. Take what he says with a small grain of salt, because (a) he was using an older version of JBoss than what exists today and (b) he is not the greatest fan of the current JBoss direction.

    Also, you can see some notes on JBoss AOP and on WebLogic AOP (in 2002) in Crazy Bob's blog (warning: frames).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  76. Dynamic proxies[ Go to top ]

    Ever since WLS 6.1, we have pondered whether we should use dynamic proxies for EJB's, and every single time (WLS 6.1, 7.0 and 8.1), we have decided against it.

    Regardless of performance problems (which are admittedly not that much of an issue any more in the latest JDK's), the reason is simple: not much to gain.

    The truth is that users only care about usability, not implementation details. As long as you provide automatic ejbc recompilation by the server, dynamic proxies don't offer much over code generation in terms of usability.

    Also, dynamic proxies are useless for CMP anyway since code generation is unavoidable (a lesson that all the EJB 2.0 vendors have eventually learned, some the hard way :-)).

    --
    Cedric
    http://beust.com/weblog
  77. Dynamic proxies[ Go to top ]

    Regardless of performance problems (which are admittedly not that much of an issue any more in the latest JDK's), the reason is simple: not much to gain.

    >


    Dynamic Proxy or JBoss AOP == no compilation (not true of AspectJ) == developer productivity == big big gain :)

    I remember you mentioning that you personally wanted to do it back in march 2000 at the OReilly conf because the compilation of the testsuite at BEA was taking the whole night whereas JBoss would take minutes. That's the gain.


    > The truth is that users only care about usability,

    yep, ejbc == bad, no compilation == good

    :)

    marcf
  78. Dynamic proxies[ Go to top ]

    Also, dynamic proxies are useless for CMP anyway since code generation is unavoidable (a lesson that all the EJB 2.0 vendors have eventually learned, some the hard way :-)).


     I think CMP can be implemented using dynamic proxies without any problems and
     it code generation too, is not it ?
    >
    > --
    > Cedric
    > http://beust.com/weblog
  79. Thanks Cameron[ Go to top ]

    I checked out Rickards blogs, and man, that guy is out of his mind! It seems like he spends most of his time posting messages about what might be running through his head at that moment. He seems to be a real JBoss hater too, hell, he seems to hate everything. Don't send me links to that guy anymore :-D

    Raffi
  80. Thanks Cameron[ Go to top ]

    Raffi: I checked out Rickards blogs, and man, that guy is out of his mind!

    He's a creative genius. Sometimes for the rest of us ordinary mortals, such people seem a little bit odd. You know that Mozart, Michaelangelo, DaVinci, Picasso, Turing, Einstein, et al were considered to be a little weird too, but I can't imagine our world today without them.

    We all know that Art is not truth. Art is a lie that makes us realize the truth, at least the truth that is given to us to understand.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  81. What?[ Go to top ]

    A creative genius? Cameron, it doesn't take a lot of creativity to insult and bad mouth the developers at JBoss. Did you read his rant on the JBoss Group and its website? C'mon man, intelligence and creativity are one thing, but if you've got nothing better to do than sit around and flat-out insult "well-known" developers in the Java community by calling them "ugly", then you're nothing short of a complete loser. Rickard is a loser, I don't care how creative that idiot can be.

    I've been on and off message boards for years now, and I've come to identify Rickard's type rather quickly as someone who acts like the knows it all and pretends that he can act smart in his words. That dude prays on others to participate in his nonsense posts simply to attack their rebuttals. I'd like to see Rickard post a picture of himself, yeah, I'd really like everyone to see it, because I'm sure Rickard is a fat ugly slob who makes love to his PC every night.

    Sorry, Cameron, you're allright, but you didn't convince me :-)

    PS: I like Mozart too :-), and Chopin, hehe,

    Raffi
  82. Re: What?[ Go to top ]

    A creative genius? Cameron, it doesn't take a lot of creativity to insult and bad mouth the developers at JBoss. Did you read his rant on the JBoss Group and its website? C'mon man, intelligence and creativity are one thing, but if you've got nothing better to do than sit around and flat-out insult "well-known" developers in the Java community by calling them "ugly", then you're nothing short of a complete loser. Rickard is a loser, I don't care how creative that idiot can be.

    >
    > I've been on and off message boards for years now, and I've come to identify Rickard's type rather quickly as someone who acts like the knows it all and pretends that he can act smart in his words. That dude prays on others to participate in his nonsense posts simply to attack their rebuttals. I'd like to see Rickard post a picture of himself, yeah, I'd really like everyone to see it, because I'm sure Rickard is a fat ugly slob who makes love to his PC every night.

    One, I think you're mixing up Rickard and Hani. Rickard only commented on technical issues (and Hani's comments were meant as a joke). Two, you couldn't be more wrong about Rickard's abilities or his personality.
  83. Re: What?[ Go to top ]

    Well, if I did mix them up, then I apologize. My mistake

    Raffi
  84. Weird People[ Go to top ]

    One, I think you're mixing up Rickard and Hani. Rickard only commented on

    >> technical issues (and Hani's comments were meant as a joke). Two, you
    >> couldn't be more wrong about Rickard's abilities or his personality

    I think both of them are weird in their own little way. I am still trying to figure out which of them is the genius, ;-).

    I routinely read/check-out both of their blogs but Rickard has not posted lately what with freeroller.net the opposite of reliability and the problems with the cache, ;-). Hani's posts (rants) more than make up for this. I am sure their is method to his madness we will only know at the end when he has changed the software world.


    William Louth
    Get JDBInsight 2.0 EA
    JInspired
  85. What?[ Go to top ]

    "A creative genius? Cameron, it doesn't take a lot of creativity to insult and bad mouth the developers at JBoss. Did you read his rant on the JBoss Group and its website? C'mon man, intelligence and creativity are one thing, but if you've got nothing better to do than sit around and flat-out insult "well-known" developers in the Java community by calling them "ugly", then you're nothing short of a complete loser. Rickard is a loser, I don't care how creative that idiot can be. "

    I believe you are not talkin about Rickard. You are talkin about Hani, the bile boy.

    "I've come to identify Rickard's type rather quickly as someone who acts like the knows it all and pretends that he can act smart in his words."

    Words+deeds: JBoss JMX kernel is pretty much grown in his head and typed by his own fingers.

    "I'd like to see Rickard post a picture of himself, yeah, I'd really like everyone to see it, because I'm sure Rickard is a fat ugly slob who makes love to his PC every night. "

    There is a tool called google which can also display images when you want it to. Once you found a picture of Rickard and look at it you will probably see that he is definitely not fat. Rather skinny. You can call him ugly though, but this is always in the eyes of the beholder. And as far as making out with the PC goes, I believe he's getting married soon, so don't tell his future wife.
  86. Thanks Cameron[ Go to top ]

    Please have some respect for Alan Turing and others you mentioned and think who you associate them with. They deserve it.

    /T
  87. In response to the original topic I would say that I view the commercial use of AspectJ is rather questionable, at least at this point of time. I still prefer Nanning or Spring-like frameworks instead of byte code augmentation or let alone new languages with a dedicated weaving process. The rational for me is that when adopting a new and such a polarized technology such as AOP for a commercial use I would prefer to gradually "open up" the features and techniques when they are becoming somewhat proven instead of the "throwing it against the wall and see what sticks"- kind of approach. Later actually works ok in academia hence the AspectJ.

    And granted the AOP landscape is fluid enough that perhaps my opinion will change in 9 to 12 months from now.

    From the marketing standpoint though I think it was a very savvy move by BEA.

    Regards,
    Nikita Ivanov
    Fitech Labs.
  88. \Ivanov\
    The rational for me is that when adopting a new and such a polarized technology such as AOP for a commercial use I would prefer to gradually "open up" the features and techniques when they are becoming somewhat proven instead of the "throwing it against the wall and see what sticks"- kind of approach. Later actually works ok in academia hence the AspectJ.
    \Ivanov\

    I don't see why you couldn't gradually "open up" via AspectJ. You _can_ use just a tiny bit of it at first. 99.9% of your code can be normal Java with just a couple of simple aspects to get your feet wet if you'd like. It's not like you're switching from Java to C++ or something.

    As for proven - Nanning 0.1 was released 7 months ago according to SourceForge, and is up to 0.9 now.
    Spring appears to be of approximately the same vintage. Both allow pretty limited interception, with a hard stop - e.g. you can quickly hit their limits, 'cuz that's all they do. AspectJ in comparison is far more mature in every measurable respect. I believe it's around 6 years old.

    It seems that you're saying that pretty limited 0.x frameworks are more "proven", which is rather strange to me. This isn't a knock on other frameworks, its just that AspectJ is the most mature and leads competitors by a very wide margin (IMHO).

        -Mike
  89. Incremental AOP[ Go to top ]

    I agree with Mike. If you want to get your feet wet, you can start off by using these AOP features in dev only (e.g. for testing). Then when you get more into it, trust it more and fall in love with it ;) you will add a couple of aspects, and then a few more and then you will think totally different about development :)

    This is what happened when people moved to OO. Everyone didn't just throw out C and jump on C++... they started to use C in OO-ish ways (the "I can do OO in C! camp), then used C++ compilers on basically C code, and it grew from there :)

    One of the nice things about AOP is that we CAN incrementally play with it on projects (and find out the anti-patterns along the way).
  90. Incremental AOP[ Go to top ]

    One of the nice things about AOP is that we CAN incrementally play with it on projects

    > (and find out the anti-patterns along the way).


    I fully agree.

    That's the reason I implemented the replicated transactional cache in JBoss (TreeCache) *without* any AOP. However there is a subclass TreeCacheAop, which provides those features.

    People can use either one. E.g. play around with the TreeCacheAop cache and see whether it fits their requirement. Wewant to force AOP down your throat.

    Bela
  91. Incremental AOP[ Go to top ]

    Sorry, of course I meant we *don't* want to force AOP down everyone's throat...
    Bela
  92. <Mike>
    It seems that you're saying that pretty limited 0.x frameworks are more "proven", which is rather strange to me. This isn't a knock on other frameworks, its just that AspectJ is the most mature and leads competitors by a very wide margin (IMHO).
    </Mike>
    I was merely referring to on-purpose (or so) limiting AOP capabilities of mentioned frameworks (primarily limiting "frivolous" pointcuts). I literally see thousands of novice AOP users flocking into AspectJ world and creating brain-dead solution b/c of the sheer "coolness" and "not-invented-here" factors (that’s one of the differences between commercial world and academia). I also strongly believe that a good portion of capabilities presented in AspectJ will fade out as much as many features of, say C++, are viewed now as redundant and rather harmful to a good OO practices. AspectJ is a great tool for a research (that’s what it was developed for). However, in my personal opinion, let me reiterate that I think that it’s not ready for a wide commercial use.

    Regards,
    Nikita Ivanov.
    Fitech Labs.
  93. <Mike>
    It seems that you're saying that pretty limited 0.x frameworks are more "proven", which is rather strange to me. This isn't a knock on other frameworks, its just that AspectJ is the most mature and leads competitors by a very wide margin (IMHO).
    </Mike>
     
    Version numbers is not the only difference between AspectJ and other AOP frameworks. Admittedly, AspectJ is the most mature implementation of AOP, but at the same time it’s a whole new language with its own syntax, compiler and unlimited (potentially dangerous) possibilities. Nanning and alike are simply frameworks with ultimate goal to steer you into proper use of AOP in Java, similarly to how Struts imposes MVC pattern on a developer.
     
    AOP is a powerful concept but is it revolutionary enough to become a new language? Does it stray so far away from what we can comfortably express in Java that a new language is inevitable or does a new language offer certain level of convenience and productivity over Java-based approach? In my opinion - No. To me, AOP is as revolutionary to the server-side development as MVC was for GUI’s at some point. We should regard AOP as a design pattern, not a new language. If we agree on it, then the approach taken by Nanning and Spring is justifiably restrictive and has certain advantage over "rock my world" AspectJ language by steering developers into proper use of aspects.

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Technology for Java and .NET
  94. \Dmitriy Setrakyan\
    Version numbers is not the only difference between AspectJ and other AOP frameworks. Admittedly, AspectJ is the most mature implementation of AOP, but at the same time it?s a whole new language with its own syntax, compiler and unlimited (potentially dangerous) possibilities.
    \Dmitriy Setrakyan\

    No, let us be perfectly clear here. AspectJ is an extension language built 100% on top of Java which accepts plain old Java code without complaint or problems (and deals quite well with .jar files compiled with plain old javac as well). You are overstating things to a very large extent when you say "whole new language".

    This is particularly true compared to the alternatives - a bevvy of XML files specifying pointcuts and mixins and aspects is also a brand new language - a highly unreadable language at that, but that's another flame war all together :-)

    As for the dangerous possibilities - AspectJ does more than most (possibly all) frameworks to point out the dangers explicitly, and the designers have worked very hard to provide language level constructs to help manage the danger and the complexity involved. In this respect every other framework has either restricted functionality to method interception (not what you can really call AOP), or has punted completely and not even really considered how to limit dangers in the language used to define and manipulate aspects.

    \Dmitriy Setrakyan\
     Nanning and alike are simply frameworks with ultimate goal to steer you into proper use of AOP in Java, similarly to how Struts imposes MVC pattern on a developer.
    \Dmitriy Setrakyan\
     
    No, they're no. They are nothing more than interceptors that can be implemented a several man-weeks of effort by any competent Java developer, with no real regard for managing the aspects in the way that OO also allows managing object complexity. I'm at a loss when people attached huge negative conotations to a well-thought-out aspect language, and then happily embrace a plethora of unreadable XML configuration files with zero static typing and call that "better".

    \Dmitriy Setrakyan\
     We should regard AOP as a design pattern, not a new language. If we agree on it, then the approach taken by Nanning and Spring is justifiably restrictive and has certain advantage over "rock my world" AspectJ language by steering developers into proper use of aspects.
    \Dmitriy Setrakyan\

    I disagree. You'll rapidly find that primitive method interception buys you very little, and that your advice is becoming more and more hideously complicated trying to do things that you can elegantly (and statically in many cases) do in AspectJ pointcuts. People will find that Spring and Nanning aren't AOP, it's just interceptors, and that plain old interceptors don't work very well in real world situations where maintenance comes into play over time. And they'll find that things like a complete lack of static typing just makes the complexity even more hard to manage.

        -Mike
  95. <Mike>
    No, let us be perfectly clear here. AspectJ is an extension language built 100% on top of Java which accepts plain old Java code without complaint or problems (and deals quite well with .jar files compiled with plain old javac as well). You are overstating things to a very large extent when you say "whole new language".

    This is particularly true compared to the alternatives - a bevvy of XML files specifying pointcuts and mixins and aspects is also a brand new language - a highly unreadable language at that, but that's another flame war all together :-)

    They are nothing more than interceptors that can be implemented a several man-weeks of effort by any competent Java developer, with no real regard for managing the aspects in the way that OO also allows managing object complexity. I'm at a loss when people attached huge negative connotations to a well-thought-out aspect language, and then happily embrace a plethora of unreadable XML configuration files with zero static typing and call that "better".

    </Mike>

    I think in some way you again bring up arguments of maturity while my initial post was not about maturity of AOP implementations at all. If maturity was my only concern, then AspectJ would be my only choice. The fundamental concern I was raising is whether I need a new language to implement a design pattern. You are of a strong opinion that AOP can only take a form of a new programming language or no form at all, I on the other hand believe that a professionally done Java-based framework approach should suffice. Let’s wait and see which shape of AOP will settle within Java community...

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Technology for Java and .NET
  96. Bigger than Java[ Go to top ]

    Dmitriy:
    The fundamental concern I was raising is whether I need a new language to implement a design pattern. You are of a strong opinion that AOP can only take a form of a new programming language or no form at all, I on the other hand believe that a professionally done Java-based framework approach should suffice.


    I think you missed Mike's point. However, and to a certain extent, you are both talking about the same thing.

    The simple truth is that something "bigger than Java" is needed to do AOP.

    Some frameworks choose to augment Java with new Java-like constructs, others use XML or metadata. All these approaches have strengths and weaknesses (although the more I use AspectJ, the more I enjoy reusing the features I know and love in Java: inheritance, composition, etc...) and as you say, time will tell if one will dominate the other.

    Right now, it seems to me that no convincing case has been made for "extremely fluid AOP" (runtime aspects)...

    --
    Cedric
    http://beust.com/weblog
  97. Bigger than Java[ Go to top ]


    > Right now, it seems to me that no convincing case has been made for "extremely fluid AOP" (runtime aspects)...
    >
    > --
    > Cedric
    > http://beust.com/weblog

    Well then, I guess you have ignored some of the other posts. Two particularly powerful uses of runtime/dynamic aspects:

    transparent transactional, ACID, pojos
    transparent pojo replication

    Bill
  98. Bigger than Java[ Go to top ]

    Bill:
    Well then, I guess you have ignored some of the other posts. Two particularly powerful uses of runtime/dynamic aspects:
     
    transparent transactional, ACID, pojos
    transparent pojo replication


    I did, and they both fall in the category of "not convincing". First of all, this approach is highly questionable, as the ensuing thread has shown, but more generally, I contend that there are better and more effective ways to solve these problems.

    Ah, and there is also the fact that "transparent transactional" is considered a Very Bad Idea. An object needs to know it is transactional so that it can take proper action if the transaction is rolled back. Or be notified if the commit fails. This is a perfect illustration of the point I am trying to make: an interesting intellectual consideration that just doesn't fly in reality.

    --
    Cedric
    http://beust.com/weblog
  99. Transactions + Value Objects[ Go to top ]

    Cedric: Ah, and there is also the fact that "transparent transactional" is considered a Very Bad Idea. An object needs to know it is transactional so that it can take proper action if the transaction is rolled back. Or be notified if the commit fails. This is a perfect illustration of the point I am trying to make: an interesting intellectual consideration that just doesn't fly in reality.

    I don't agree. I think that being able to design "value objects" (for lack of a better term) and having them be [optionally] managed in a transactional manner is a really good thing, if the developer makes a conscious decision to do so. So some of the developer's object may be aware of the transactionality, but the "pojos" do not necessarily have to be aware.

    (I don't necessarily agree with Bill's approach, but time will sort out the best ways to do it.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  100. Transactions + Value Objects[ Go to top ]

    \Cameron\
    I don't agree. I think that being able to design "value objects" (for lack of a better term) and having them be [optionally] managed in a transactional manner is a really good thing, if the developer makes a conscious decision to do so. So some of the developer's object may be aware of the transactionality, but the "pojos" do not necessarily have to be aware.
    \Cameron\

    I agree completely. The key point for me is "conscious decision", and especially that some other app code outside of the POJO may be aware of transactionality. In AspectJ, you can have a graph of POJOs that act as a pure domain model, and then define abstract aspects that define something like transactionality, and then allow concrete aspects that define what transactionality means for individual domain classes. You can also often cover multiple "simple" classes with a single default concrete aspect. The result is your domain model is pure as a white Christmas, transactions are modelled seperately, but a developer can also control what transactionality means in specific cases in seperate aspects.

    The above scenario does _not_ sound like what JBoss AOP is doing with POJOs - I haven't heard of the concept of abstract aspects that can be overriden to give specific concrete behavior when the _developer_ wants it (developer, not container). JBoss seems to be all about the container and canned aspects doing everything, other aspect systems exhibit much more cooperative behavior that makes alot more sense in the real world (IMHO).

         -Mike
  101. \Dmitriy Setrakyan\
    I think in some way you again bring up arguments of maturity while my initial post was not about maturity of AOP implementations at all. If maturity was my only concern, then AspectJ would be my only choice.
    \Dmitriy Setrakyan\

    I must have misunderstood the thrust of your post then - you seemed to be stating that Spring and Nanning type frameworks were more mature in some manner than AspectJ. In any case, sorry for the misinterpretation on my part.

    \Dmitriy Setrakyan\
     The fundamental concern I was raising is whether I need a new language to implement a design pattern. You are of a strong opinion that AOP can only take a form of a new programming language or no form at all, I on the other hand believe that a professionally done Java-based framework approach should suffice. Let?s wait and see which shape of AOP will settle within Java community...
    \Dmitriy Setrakyan\

    I think this is where we have a fundamental disagreement. In my mind, saying that AOP is a design pattern is similar to saying OO is a design pattern. For example, that you can do OO in C (possibly with a fancy runtime to help with the OO). You can kinda do OO in C, but it's a very painful experience, and rather hard to implement and maintain at the application level, or so limited in its abilities that you miss out on the best advantages of OO.

    Likewise, with configuration-driven AOP frameworks, you may be sort of doing AOP, but it seems a painful route to take, and frameworks that have shown up to date are _definitely_ more limited in their capabilities than something like AspectJ. It's my opinion that ultimately relegating AOP to something like XML files (a shocking jolt from doing Java code) and the limitations of the existing frameworks are going to frustrate people ultimately more than help them, and they're going to miss out on what a more full-featured AOP implementation can do.

        -Mike
  102. <Mike>
    I think this is where we have a fundamental disagreement. In my mind, saying that AOP is a design pattern is similar to saying OO is a design pattern.

    ...with configuration-driven AOP frameworks, you may be sort of doing AOP, but it seems a painful route to take, and frameworks that have shown up to date are _definitely_ more limited in their capabilities than something like AspectJ. It's my opinion that ultimately relegating AOP to something like XML files (a shocking jolt from doing Java code) and the limitations of the existing frameworks are going to frustrate people ultimately more than help them, and they're going to miss out on what a more full-featured AOP implementation can do.

    </Mike>

    I partially agree with you that the language should be aware (to a certain extent) of the AOP concept. Most of the current "configuration-driven AOP frameworks" attempt to use XML largely to compensate for the lack of native support for metadata attributes in Java. However, with advent of JDK 1.5 we should observe a definite decline of XML code in AOP frameworks. AspectJ is a whole another beast altogether which uncontrollably leads a developer into wild jungle of AOP, and if we adopt it at this time and age, then undoubtedly "giant-on-straw-legs" designs will start popping up in software.

    I would prefer to see Java slowly evolve by introducing AOP-aware constructs and have frameworks guide developers into proper AOP designs. After all, there is no obious need for AspectC# granted that C# has a native support for metadata atributes.

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Technology for Java and .NET
  103. Java 1.5 metadata[ Go to top ]

    This isn't going to solve the problem in the most general cases, because it violates the idea of encapsulation and a class doing one thing and doing it well. A fundamental idea of AOP is that a class doesn't need to know about cross-cutting concerns, and they are handled externally to it. If you buy into that idea, then putting meta-tags into a primary class misses the entire point of seperating out concerns. Think of a POJO which has 3 aspects working against it (let's say logging, transactions, persistence) - you'll need three sets of metatags embedded in your POJO. This is a nice declarative model, but not really seperating out concerns.

    I'm not saying metatags in concert with AOP isn't useful - it certainly is. But it's not really sufficient. AspectJ comes at things from an entirely different angle that I believe is very managable, and leads to alot of reuse possibilities with a high degree of control as well. What you're describing is nothing more than interceptors operating on declarative meta-data, which isn't all that interesting to me.

        -Mike
  104. Java 1.5 metadata[ Go to top ]

    I agree with Mike. If we have to modify the POJO's source code in order to add a new aspect for it, then the transparency is lost. I can't see another way to do it unless using a third file (XML) stating what aspects are applied to what POJOs or something like that.
  105. Java 1.5 metadata[ Go to top ]

    This isn't going to solve the problem in the most general cases, because it violates the idea of encapsulation and a class doing one thing and doing it well.


    This violation of encapsulation is just plain nonsense. Applying transacton and security tags is just the same as marking a field as transient, or a class as Serializable. These are all attributes of the class.

    >A fundamental idea of AOP is that a class doesn't need to know about cross-cutting concerns, and they are handled externally to it. If you buy into that idea, then putting meta-tags into a primary class misses the entire point of seperating out concerns. Think of a POJO which has 3 aspects working against it (let's say logging, transactions, persistence) - you'll need three sets of metatags embedded in your POJO. This is a nice declarative model, but not really seperating out concerns.
    >

    Developers disagree, hence the birth of XDoclet in EJB land. As a developer of a subsystem, you want to know exactly what is going on. Tags are great for this because they describe WHAT you want to do, but you don't care HOW it is done. I like to think of MetaTags + AOP as pluggable Java keywords. Framework developers can use MetaTags + AOP to expand the Java language in a pluggable fashion. Ultra-power IMNSHO.

    Not only that, but the code is more readable. Instead of some regular expression in some other file, you can look at a class and know exactly what are its attributes. Hey, this method is transactional, hey this method is secure. What you don't need to know is that a security methods triggers the application of 3 advices, or that persistence triggers the addition of an Introduction.


    In JBoss AOP, we can simulate JSR-175 metadata through XML or XDoclet tags that are similar to JSR-175 that generate this XML. We also allow pointcuts on these metatags. Strangely enough, we have found so far that our system-level aspects fit into 2 different catagories

    1. Tag triggered Aspects (tx, security, locking, etc..)
    2. Dynamic aspects (caching, ACID pojos, etc...)

    Sure you could apply our Tag triggered aspects via straight separation of concerns, but that just won't be the practice in general. If EJB has taught us anything, it has taught us that developers hate separation of concerns. They want to know about the WHAT. C# got something right.


    > I'm not saying metatags in concert with AOP isn't useful - it certainly is. But it's not really sufficient. AspectJ comes at things from an entirely different angle that I believe is very managable, and leads to alot of reuse possibilities with a high degree of control as well. What you're describing is nothing more than interceptors operating on declarative meta-data, which isn't all that interesting to me.
    >

    Maybe not interesting to you, but exteremely powerful.

    Bill
  106. Java 1.5 metadata[ Go to top ]

    \Bill Burke\
    This violation of encapsulation is just plain nonsense. Applying transacton and security tags is just the same as marking a field as transient, or a class as Serializable. These are all attributes of the class.
    \Bill Burke\

    Here's a scenario for ya. I've got a fairly generic "EmailMsg" class that describes an e-mail message. I'd like to re-use this class in lots of systems 'cuz its clean and simple and does what I need, and isn't coupled with anything else.

    In system A, I'm adding a specific and weird logging aspect to EmailMsg to log things in a strange format to make operations happy. In system B, I'm adding a generic logger and making e-mail transactional.

    In this sort of world, you can have real POJOs that describe domain/business problems, and then add in aspects specific to the application to address additional concerns of the application. The POJO is reusable, the logging/transaction stuff is plugged in via aspects.

    You can't do with this meta-tags built into the POJO, because it locks the POJO into one model and set of concerns. Additionally, the POJO writer may not be the right person to give a fart about secondary concerns - they're the domain expert modelling the domain. Again, in this situation, your POJO is supposed to be focused on its main concern, not littered with meta-tags that have nothing to do with what the POJO is modelling.

    \Bill Burke\
    Developers disagree, hence the birth of XDoclet in EJB land.
    \Bill Burke\

    Ah, I see. One tool which eliminates the drudgery of EJBs invalidates the entire generalized AOP concept.

    I think, perhaps, you are extrapolating way too much out of way too little data.

    \Bill Burke\
    Sure you could apply our Tag triggered aspects via straight separation of concerns, but that just won't be the practice in general. If EJB has taught us anything, it has taught us that developers hate separation of concerns. They want to know about the WHAT. C# got something right.
    \Bill Burke\

    You're taking one very specific example and trying to generalize it. And failing in the attempt. What EJB tought us is that EJBs are over the top and over done. Developers hatred of EJBs has nothing to do with seperation of concerns, and everything to do with just having to write too much damned boilerplate and config files without any choice.

    Real AOP gives developers choice, not mandates. I get the impression that you haven't gone into AspectJ very much, which is a pity. Where you put your Aspects is up to you, what you do in aspects vs. plain old Java code is up to you. Highly structured and consistent hierarchies of Aspects can be built using Java concepts of inheritance, abstractness, and overrides.

    What you're describing is nothing more, really, then declarative programming. In fact, the new EJB model will allow people to do this with mere code generation via new EJB compilers. It saves typing, and three cheers to that, but it's not AOP, and it's not going to really make creating software that much more quicker or reliable. It's a small convenience.

         -Mike
  107. Java 1.5 metadata[ Go to top ]

    \Bill Burke\

    > This violation of encapsulation is just plain nonsense. Applying transacton and security tags is just the same as marking a field as transient, or a class as Serializable. These are all attributes of the class.
    > \Bill Burke\
    >
    > Here's a scenario for ya. I've got a fairly generic "EmailMsg" class that describes an e-mail message. I'd like to re-use this class in lots of systems 'cuz its clean and simple and does what I need, and isn't coupled with anything else.
    >
    > In system A, I'm adding a specific and weird logging aspect to EmailMsg to log things in a strange format to make operations happy. In system B, I'm adding a generic logger and making e-mail transactional.
    >
    > In this sort of world, you can have real POJOs that describe domain/business problems, and then add in aspects specific to the application to address additional concerns of the application. The POJO is reusable, the logging/transaction stuff is plugged in via aspects.
    >
    > You can't do with this meta-tags built into the POJO, because it locks the POJO into one model and set of concerns. Additionally, the POJO writer may not be the right person to give a fart about secondary concerns - they're the domain expert modelling the domain. Again, in this situation, your POJO is supposed to be focused on its main concern, not littered with meta-tags that have nothing to do with what the POJO is modelling.
    >

    Then don't use metatags for this purpose, or, with JBoss AOP, declare the metadata in XML rather than using a metatag, or just use a non-metatag pointcut to apply your concerns. What's the big deal here? I'm saying Metatags + AOP is powerful and useful, but not the be-all, end-all. I'm saying that from my experiences in EJB land where there are a number of predefined aspects, developers prefer metatags. Go to the XDoclet site, and you'll see mappings for much more than just EJB.

    > \Bill Burke\
    > Developers disagree, hence the birth of XDoclet in EJB land.
    > \Bill Burke\
    >
    > Ah, I see. One tool which eliminates the drudgery of EJBs invalidates the entire generalized AOP concept.
    >

    EJB is a good and powerful spec. Declarative transactions and security are ultra-useful and are in reality system-level aspects and these are real-world aspects. I wasn't invalidating generalized AOP, but rather stating that aspects triggered by metatags are more readable and maintainable over the long run.

    > I think, perhaps, you are extrapolating way too much out of way too little data.
    >

    Go to xdoclet.sourceforge.net and you'll see how many things Attribute-Oriented Programming is used for. If you combine AOP with AOP, you have a simple way for app developers to apply the functionality provided by a framework.

    > \Bill Burke\
    > Sure you could apply our Tag triggered aspects via straight separation of concerns, but that just won't be the practice in general. If EJB has taught us anything, it has taught us that developers hate separation of concerns. They want to know about the WHAT. C# got something right.
    > \Bill Burke\
    >
    > You're taking one very specific example and trying to generalize it. And failing in the attempt. What EJB tought us is that EJBs are over the top and over done.

    You did the same with your EmailMsg example. Except, the EJB concepts are bitmore relevant and applicable.

    Yes EJBs are over the top if the developer uses it over-the-top. EJBs have their purpose and are powerful. CORBA showed us what functionality we needed to build a distributed system. EJB was the 1st attempt to simplify and package this functionality. Some form of AOP + middleware will be the future. My hope is that it's JBoss AOP.

    >Developers hatred of EJBs has nothing to do with seperation of concerns, and everything to do with just having to write too much damned boilerplate and config files without any choice.

    I disagree. The developers I have contact with through consulting, support, and training that use XDoclet don't like the separation of concerns in EJB.


    >
    > Real AOP gives developers choice, not mandates. I get the impression that you haven't gone into AspectJ very much, which is a pity. Where you put your Aspects is up to you, what you do in aspects vs. plain old Java code is up to you. Highly structured and consistent hierarchies of Aspects can be built using Java concepts of inheritance, abstractness, and overrides.
    >

    Guess you haven't gone into JBoss AOP much either, which is a pity. Not as rich yet as AspectJ, but you have choice, aspects triggered by metatags is just one of them. It is my personal opinion, that aspects triggered metatags are easier to apply and make more sense from code usability and maintainability standpoint in many many cases. Transactions, security, tx locking, persistence, just to name a few.


    > What you're describing is nothing more, really, then declarative programming. In fact, the new EJB model will allow people to do this with mere code generation via new EJB compilers. It saves typing, and three cheers to that, but it's not AOP, and it's not going to really make creating software that much more quicker or reliable. It's a small convenience.
    >
    >      -Mike

    As I said before, metatags are much more than saving you from corporal-tunnel-syndrome, they are a way to describe your class in a more detailed way. A framework developer can provide metatags as an extended vocabulary or syntax for application developers and have aspects that are triggered by these metatags, or generic aspects that use the metadata to do tasks based on this metadata.

    A perfect example of this is the synchronized keyword in java. Unlike transient or Serializable this actually triggers specific funtionality. With metatags + AOP you could invent a tx-synchronized keyword that locks a class for the duration of a transaction.

    All and all, I think metatags + AOP is more applicable to the app-developer. Just my opinion. We know yours.

    Bill
  108. Java 1.5 metadata[ Go to top ]

    As I said before, metatags are much more than saving you from corporal-tunnel-syndrome, they are a way to describe your class in a more detailed way. A framework developer can provide metatags as an extended vocabulary or syntax for application developers and have aspects that are triggered by these metatags, or generic aspects that use the metadata to do tasks based on this metadata.

    >
    > A perfect example of this is the synchronized keyword in java. Unlike transient or Serializable this actually triggers specific funtionality. With metatags + AOP you could invent a tx-synchronized keyword that locks a class for the duration of a transaction.
    >
    > All and all, I think metatags + AOP is more applicable to the app-developer. Just my opinion. We know yours.
    >
    > Bill

    I would have thought that your transactional aspect would have had to deal with isolation requirements (that's the I in ACID after all) inherently. If you're putting the burden on the application developer to come up with a plausible mechanism to deal with this by a combination of meta-tags and AOP, that's not "more applicable to the app-developer": that's a huge error.
  109. Java 1.5 metadata[ Go to top ]

    \Bill Burke\
    Then don't use metatags for this purpose, or, with JBoss AOP, declare the metadata in XML rather than using a metatag, or just use a non-metatag pointcut to apply your concerns. What's the big deal here? I'm saying Metatags + AOP is powerful and useful, but not the be-all, end-all. I'm saying that from my experiences in EJB land where there are a number of predefined aspects, developers prefer metatags. Go to the XDoclet site, and you'll see mappings for much more than just EJB.
    \Bill Burke\

    My original point was about conceptually violating encapsulation, and the idea of combining multiple purposes into a single class being a bad idea, to which you replied "[this] is just plain nonsense". You haven't shown how it's nonsense, instead you've switched arguments. As a bit of constructive criticism, I've seen frustration on TSS in asking you questions from several people because your answer doesn't often match the question :-) It's frustrating for you to call something "nonsense", and when challenged for you to go off in a completely different direction and implicitly leaving the "nonsense" comment out in the air as if you've answered it (but haven't).

    \Bill Burke\
    EJB is a good and powerful spec. Declarative transactions and security are ultra-useful and are in reality system-level aspects and these are real-world aspects. I wasn't invalidating generalized AOP, but rather stating that aspects triggered by metatags are more readable and maintainable over the long run.
    \Bill Burke\

    Declarative programming _is_ useful, but in your statements you keep mixing that into AOP until the two concepts are so blurred that it's hard to know which you're talking about at a given point. Declarative programming is useful, but it isn't AOP - as I said, you can implement declarative programming easily without AOP.

    \Bill Burke\
    You did the same with your EmailMsg example. Except, the EJB concepts are bitmore relevant and applicable.
    \Bill Burke\

    The difference is subtle but very real, I'm afraid. I'm talking about domain modelling and design and seperation of concerns. The constraints there are what the designers decide. EJBs are a very specific technology with very specific constraints.

    \Bill Burke\
    I disagree. The developers I have contact with through consulting, support, and training that use XDoclet don't like the separation of concerns in EJB.
    \Bill Burke\

    Uh, sure, I'm sure most developers out there are complaining "I hate the seperation of concerns in EJB", and that's one of their biggest complaints. Speed and checked exceptions and too many files and a warped entity model are no where near the top of their list. Yeah, sure.

    \Bill Burke\
    Guess you haven't gone into JBoss AOP much either, which is a pity. Not as rich yet as AspectJ, but you have choice, aspects triggered by metatags is just one of them. It is my personal opinion, that aspects triggered metatags are easier to apply and make more sense from code usability and maintainability standpoint in many many cases. Transactions, security, tx locking, persistence, just to name a few.
    \Bill Burke\

    I regularly look through the JBoss CVS for interesting bits (interesting to me :-) - JMS, JTA, XA, AOP. I probably know far more about JBoss AOP than you do about AspectJ. And my "is a pity" comment is due to the fact that you're trying to implement AOP (with much fanfare) without much knowledge about the most widely known, most widely used, and most widely touted AOP system on the planet.

    Get a good book on AspectJ, check out things beyond the rich pointcuts to things like abstract concerns and abstract pointcuts, then look at design patterns like Observer implemented in AspectJ aspects, and then you'll understand some of what I'm talking about.

        -Mike
  110. AOP as a framework?[ Go to top ]

    Posted By: Dmitriy Setrakyan on July 24, 2003 @ 12:06 AM A:
    > The fundamental concern I was raising is whether I need a
    > new language to implement a design pattern. ...
    >
    > I on the other hand believe that a professionally done
    > Java-based framework approach should suffice. Let’s wait
    > and see which shape of AOP will settle within Java community...

    OK, let's challenge your belief! :)

    Can you show how you could implement the AspectJ figures package example[1], in a way that satisfies the following properties:

      - doesn't require changes or additions to JLS (your requirement)
      - is modular, meaning
         - is invisible in the Point and Line classes (aka oblivious)
         - all the code for DisplayUpdating is in one place
      - is efficient
      - generates good error messages for simple errors at compile time

    I can't do this. The kernel of AspectJ is the simplest mechanism I know of to achieve this kind of thing, but it is an extension to Java. (It meets a few more typical language design requirements as well.) (By kernel I mean advice, and the 5 or 6 most important pointcuts.)

    You might argue the example is too trivial, but the reason the example is still with us is that it captures a lot of what a mechanism for modularizing crosscutting concerns has to do.

    [1] The example appears in many places, including the CACM special issue, and the following (too academic) paper: http://www.cs.ubc.ca/~gregor/kiczales-ECOOP2001-AspectJ.pdf.
  111. I respect your points of view as the one from an academia side. And as I said my views are only my views. I believe that my view on commercial software development are significant different from one from academia front, and it’s understandably so.

    I also think that all opinions here are of the personal views only. There has not been an established and widely accepted direction of AOP developing and hence discussion like this trying to voice personal views.

    As a side note, this is a little bit of a downside of such discussion in that that most of them can go endlessly without much residual, throwing examples and questions, providing arguments and contra-arguments of all sorts. I value discussions like this one not because it proves to me something but because I can “hear” what other people think. I really think that proving and convincing someone is completely different venue and should be done on a slightly different level.

    As someone said earlier, let see and wait (actively!) what shape AOP will take.

    Regards,
    Nikita Ivanov.
    Fitech Labs
  112. <Mike>
    No, let us be perfectly clear here. AspectJ is an extension language built 100% on top of Java which accepts plain old Java code without complaint or problems (and deals quite well with .jar files compiled with plain old javac as well). You are overstating things to a very large extent when you say "whole new language".
    </Mike>

    Mike, you have no idea. In terms of language AspectJ is *not* an extension of Java. Go start counting. AspectJ has almost as much keywords as the whole JSDK1.4 system. It extents the key constructs (class, method, field) of the Java Language in a sometimes quite crude way. One of my key questions I pose to so called AOP advocates is "Explain the conceptual difference between a class, an aspect and a concern".

    After reading about 100 papers on the issue, it is clear to me that literally noone has an idea about what AOP really is _as a concept_- let alone a common one! What I generally hear is "Oh, it's something like interception but at runtime and a lot more powerful" and "Oh, it's messing around with the inheritance and class structure hierachy in any way you want". Of course that is put in a slightly more academic and bloated way, but hey, it does not change the general content of the message.

    I have the occasional pleasure of analysing 1000+ classes J2EE codebases for errors and performance problems. Most problems are *still* because people can not distinguish between a class and an instance, are not able to understand the JSP request processing cycle, use but don't understand implications of CMP, do not understand what polymorphism is, grossly underestimate the impact of creating (and filling) 1000 element String arrays in every call into a server side method etc, etc. Now they consider it hip to pep up their code with a little bit AspectJ as well. Gives me the creeps.
  113. \Karl Banke\
    Mike, you have no idea. In terms of language AspectJ is *not* an extension of Java. Go start counting. AspectJ has almost as much keywords as the whole JSDK1.4 system. It extents the key constructs (class, method, field) of the Java Language in a sometimes quite crude way. One of my key questions I pose to so called AOP advocates is "Explain the conceptual difference between a class, an aspect and a concern".
    \Karl Banke\

    You must have a radically different definition of extension than I do. AspectJ is Java with new language constructs layered on top of it. Aspects can contain plain old Java methods, advice bodies are written in Java code, Java inheritance scoping et al are fully supported. Joinpoints, pointcuts, and advice signatures are not Java - they're extensions on top of Java.

    In any case - you may AspectJ is a large extension, but it's still an extension. Saying it's not is either being stubborn for stubborn's sake, or spreading FUD.
    Methods are still methods, classes are still classes, fields are still fields, the JVM still runs everything.

    As for what a class is - as a Java programmer, I hope you know what a class is :-) A concern is conceptual, basically a seperation of requirements, not something physically represented in one obvious place in the code (just like OO encapsulation is not a language construct, it's a goal and a concept). An Aspect is a modular collection of pointcuts and advice that together address a concern, and interact with other aspects and Java classes.

    Addressing the rest of your post - yes, you can argue against AOP as a concept, and there also isn't any standardization. Those are valid issues, and some people may get the heebie jeebies and walk away from it entirely. But if you have an interest in AOP, IMHO AspectJ is right now the best approach to take.

         -Mike
  114. correcting a few points[ Go to top ]

    I just have to correct some of the mis-perceptions of AOP and AspectJ here...

    > Posted By: Nikita Ivanov on July 23, 2003 @ 08:19 PM
    > In response to the original topic I would say that I view the
    > commercial use of AspectJ is rather questionable, at least at
    > this point of time.

    This may be your view. But AspectJ has had commercial users for almost
    three years, and has been used in significant application server pilot
    projects for more than a year.

    > Posted By: Nikita Ivanov on July 23, 2003 @ 08:19 PM
    > I still prefer Nanning or Spring-like frameworks instead of byte code
    > augmentation or let alone new languages with a dedicated weaving process.
    > The rational for me is that when adopting a new and such a polarized
    > technology such as AOP for a commercial use I would prefer to
    > gradually "open up" the features

    This is a good approach. But it means you should prefer AspectJ, because
    AspectJ is actually more restrictive in all sorts of good ways than the newer
    frameworks. It inherits static typing from Java. Its easy to make a structure
    browser that shows exactly what the crosscutting is. All in all, AspectJ
    much more guides people towards limited and modular uses of AOP. Five years
    ago AspectJ was dynamically typed and loose in the way the newer frameworks
    are. In large part its five years of user feedback that have made it the
    more restrictive system it is now.

    > Later actually works ok in academia hence the AspectJ.

    AspectJ is not an academic system. It has many, many more commercial users
    than academic users. All in all, AOP has followed path much like OOP. The
    early AOP R&D was very much real-application inspired and connected.
  115. JBoss Leads - Really?[ Go to top ]

    "The technology doesn't lie and JBoss leads."

    To make this statement you must be smoking some kind of pot. JBoss is years behind Weblogic as of today. While BEA chose to solve customer problems, JBoss chose to go with hype(Putting AOP at a higher priority compared to JMS clustering or decent console to look at) which would get them some Press Releases.
  116. AOP Leadership[ Go to top ]

    At the risk of lengthing a pointless debate over who's leading who in AOP (which incidentally isn't even JBoss or BEA), only time will tell. IMHO leadership won't be decided simply by who has released what first, but simply who furthers the applications of AOP to solve problems. Leaders are made over time, and if one framework wants to go it alone, then good luck to them.
  117. There is a ton of noise in this thread but I guess that it is at least a positive indicator that people are paying attention. I think AOP will offer significant contributions and improvements to declarative technology regardless of who is fueling that synergy.
  118. Sam and Cedirc - it's great to see the work you've done has been released. I think you have put your effort in the right area, by building on the
    most mature AOP implementation and then defining useful applications.
    Defining a standardized set of pointcuts for WLS is a great step towards
    reusable libraries. Adrian Colyer and I have started work on something similiar for a reusable library of J2EE aspects. Adrian and I think it would be even better to create a standard library for any J2EE that's released by the AspectJ project. The WLS specific pointcuts could be incorporated with extensions or implementations. I think it would be great for users to have a J2EE library that the WLS one extends, and it would also be good to extend AspectJ support for reusable libraries (Adrian has already made a suggestion based on this). This work would also be easily to translate to other AOP frameworks (as long as they have a rich enough model for pointcuts and mechanisms for reuse).

    Having AspectJ weaving integrated into the WLS classloader is a big win
    (having recently worked to get Tomcat to compile JSP's with AspectJ this
    capability would be most welcome).

    I'd also like to pick up on the topic of dynamic AOP. Having static AOP, like
    static OO, gives you two very powerful capabilities: good tools support, and
    compile-time checking. If you haven't seen how AspectJ IDE support allows
    developers to see how aspects affect their base code, you should take a look
    (e.g., in AJDT for Eclipse). It's not generally possible to identify advice or introductions that are deployed dynamically when viewing source (or UML).

    While there are some use cases where dynamic AOP would be helpful, I think AOP systems need to support static AOP primarily (just as you wouldn't build a Java system using only reflective calls!)

    One can also write AspectJ aspects to address a handful of system-wide dynamic concerns that many POJOs might implement. If you made them all implement a _marker_ interface like Advisable (as JBoss does), then you can write advice with a test for whether this object is affected (using introductions or a hash map). If the number of aspects gets large, then the performance cost of these tests would favor a truly dynamic approach. But for a small number, this should be quite competitive.