1 2 Previous Next 25 Replies Latest reply on Jan 7, 2003 7:37 AM by Sacha Labourey

    Using AspectJ weaver and model

    Wes Isberg Newbie

      It is fantastic that JBoss is picking up AOP! AOP is a good antidote to much of the complexity making distributed systems hard to build.

      I'm familiar with AspectJ, which has just released a beta of its open-source bytecode weaver, built on apache's BCEL. With this you can weave aspects into classes at load time. I believe the weaver solves a lot of the tricky problems with implementing AOP (e.g., inlining of advice, visibility of inter-type declarations (open classes), etc.). It seems to me that you could leap ahead of your current path by building on the weaver. One option for your implementation is to use the AspectJ weaver as a library to implement your limited model.

      A more interesting option is to instead implement the AspectJ programming model for J2EE, using your deep understanding of the jboss runtime (e.g., doing cflow over distributed calls, implementing some form of distributed aspects), making you the first app server to do so. There are a fairly small (and non-trivial) set of requirements for doing this. Once the plumbing is done, programmers would enjoy the benefit of the full programming model, in their regular applications, or, if they are using J2EE, with JBoss.

      Rolling your own AOP model is tempting to open-source developers, scratching the itch of what they need by implementing in the way they know how, and enjoying the learning experience along the way. But will what you end up with provide lasting benefit? JBoss is probably the best proof that open-source development can move faster and produce a better product than commercial development -- for well-understood programming models. But it's less clear that JBoss grows by pushing a new variant of AOP which can only be used in J2EE and only in JBoss -- including developing the tools and training the mindshare to get people to adopt a new model. AOP that happens with XML or during deployment is forced into the hands of specially-trained application assemblers and deployers, while general-purpose AOP can also be used by developers themselves, using a language as close to Java as possible.

      As a tool component, the weaver could be used at any bytecode point, from the end of a Java compile through static analysis tools, RMIC, or class loading. The compiler does some whole-program analysis that might be quite fruitful to build other static tools with, or you might even be able to implement your JBoss variant model completely with binary aspects. That means the weaver could play a role at a number of points in your tool chain, and you might need only write the aspects themselves. That makes it more flexible from a feature-set standpoint.

      As a business model, I imagine that JBoss would come out of the box with configurable aspects for doing the kind of high-level profiling or first-failure data capture that systems analysts need to understand their systems. Beyond that, JBoss consultants could sell configurable binary aspects (e.g., for caching), or build their own tools based on the weaver and compiler, reading aspects in binary or source form (even your current XML, if you insist!). All that is possible today with the AspectJ because it is open-source.

      So this is what I see:
      - you decided on your implementation strategy before looking at the bytecode weaver
      - you're building your AOP model from the ground up as interceptors+ in XML, which is not a usable for most developers except for relatively simple problems
      - your model is specific to particular itches of JBoss users, so it's not a growth feature.

      This is what I recommend:
      - using the open-source AspectJ bytecode weaver to implement your model
      - implement the AspectJ model, which has evolved over three+ years of developer feedback about what makes sense and what doesn't.

      I believe that AOP as a technique is orthogonal to the environments AO programs run in. The best thing for environments to do is to implement the standard programming model, which benefits both the environment and the model. I'd be surprised if you didn't get support from the AspectJ team and community in following this path.

      I'm psyched about JBoss doing AOP in *any* form. But imho AspectJ is the best-available form and has the best chance of being widely adopted, and building on the AspectJ weaver is the fastest and best path for JBoss to bring AOP to J2EE.

      Wes

        • 1. Re: Using AspectJ weaver and model
          Tim Fox Master

          > to say you would not use an aop framework unless it is
          > written in 100% java is like saying i would not use an
          > object oriented framework unless it is written in C.

          We had this same discussion in Geneva and I agree with your point of view. If aspects do prove themselves useful then there will be an AOP language eventually.

          I can do OOP in C but I do prefer Java for the task...

          • 2. Re: Step debugging JSP pages
            marc fleury Master

            I now can debug JSP code. Hope I did not waste anybody's time. It had to do with both Lomboz and JBossIDE plug-ins were installed. This kind of mistake tends to be made easily by a newbie like myself having a couple of days of experience with J2EE and trying to go through a sea of information to get a development environment set up. It sure was not a walk in the park, but I finally got the tutorial example (with my own JSP experiment) working! Quite frankly, I have been spoiled by M$'s Visual IDE and was trying to check out J2EE/JBoss, and man, I'm impressed. Hats off to people who worked on JBoss and Eclipse coz they rock!

            Jim

            • 3. Re: Using AspectJ weaver and model
              Talip Ozturk Newbie

              I don't think AspectJ is the best choose for JBoss aspect implementation. imho jboss' aspect implementation looks good. there is no need for aspecj route. One comment on JBoss aspect implementation. the implementation should keep jboss invocation style (which is based on jmx and dynamic proxy) separate as much as possible. i think Hiram is doing pretty good job of keeping it as generic as possible and hooking jboss invocation stack throu JMXInvokerInterceptor. on the other hand instead of hard coding method filtering as it is done in GetSetInterceptor class, MethodName filtering should be generic. jboss-aspect framework proactively should be able to filter the interceptors based on method-names.

              it is not necessary but Nanning project (http://nanning.sourceforge.net) would be something nice to check out. it is heavily based on dynamic proxy, round-advice, very similar to jboss-aspect.

              btw, i guess i wasn't supposed to post here as i am not jboss developer, even though i wish i could be sometime. let me know if i should post anything here.

              --talip

              • 4. Re: Using AspectJ weaver and model
                marc fleury Master

                > I'm familiar with AspectJ, which has just released a
                > beta of its open-source bytecode weaver, built on
                > apache's BCEL. With this you can weave aspects into
                > classes at load time. I believe the weaver solves a
                > lot of the tricky problems with implementing AOP
                > (e.g., inlining of advice, visibility of inter-type
                > declarations (open classes), etc.). It seems to me
                > that you could leap ahead of your current path by
                > building on the weaver. One option for your
                > implementation is to use the AspectJ weaver as a
                > library to implement your limited model.

                Ok I am not really familiar with the weaver. We have decided to go with a competing implementation of BCEL wich is javassist and gives us a more powerful API for the injection of bytecode.

                My question to you is this: One of the very nice features of the way we do things right now is that the behavior that is being injected comes from a .class file that was written in java. What this says is that implementing something like TX propagation reads

                public Invocation invoke(Invocation invocation) {

                //extract the TX and put it in the invocation for propagation
                invocation.payload.add("TX", tm.getCurrentTransaction();
                }

                and we are done for the local vs remote call it reads

                public Invocation invoke(Invocation invocation) {

                if (isLocal()) return local.invoke(invocation);

                else return invocation.getInvoker().invoke(invocation);
                }

                what I am trying to say is that this is a TRIVIAL way to implement added behavior. Our users dig that as it enables them to easily add their aspect to the chain and we as container developers dig that as it makes for very easy maintenance. AND IT IS ALL IN JAVA, no need for language or compilers.

                So my question is "in what language do I write the additional behavior that gets weaved in the class". If it is in some bytecode level API, or slightly above API, then I have NO interest in it.

                Can you shed some light on this?

                > you end up with provide lasting benefit? JBoss is
                > probably the best proof that open-source development
                > can move faster and produce a better product than
                > commercial development -- for well-understood
                > programming models.

                Appreciate the compliment.

                > But it's less clear that JBoss
                > grows by pushing a new variant of AOP which can only
                > be used in J2EE and only in JBoss -- including
                > developing the tools and training the mindshare to
                > get people to adopt a new model. AOP that happens

                OK let's be clear. The model that Rickard introduced in JBoss about 2 years ago and that we have matured is hardly revolutionary. In the Gang Of Four Pattern book (the Gamma thingy) the interceptor chain is called "chain of responsibility" and is a well known pattern for the past 20 years or so.

                A object really looks like this (most common case)

                I -- ||||-- O

                where the front I is the interface (or native object for pojos) and the front -- represent the Dynamic Proxy that creates the Invoke signature. The interceptors are the | lines so here we have 4 interceptors with code like the stuff I showed above. The class is OUTSIDE the initial class and all that the bytecode generation does is the front outsourcing of the calls to a chain of interceptors and the back adaptation to the final object (reflective call). It is clear with the WYSIWYG development you have above.

                > with XML or during deployment is forced into the
                > hands of specially-trained application assemblers and
                > deployers, while general-purpose AOP can also be used
                > by developers themselves, using a language as close
                > to Java as possible.

                See I have a disconnect here. You are talking about a "language as close to java as possible" which implies a new compiler and additional compilation step. I am talking about STRAIGHT JAVA and XML that says "please put these interceptors at these pointcuts". I seriously disconnect on which one is simpler. See my point?

                > binary aspects. That means the weaver could play a
                > role at a number of points in your tool chain, and
                > you might need only write the aspects themselves.

                Can you give me a specific example?

                > As a business model, I imagine that JBoss would come
                > out of the box with configurable aspects for doing
                > the kind of high-level profiling or first-failure
                > data capture that systems analysts need to understand
                > their systems.

                Again example please, sounds good.

                > Beyond that, JBoss consultants could
                > sell configurable binary aspects (e.g., for caching),

                we consult on these aspects already we build caching interceptors in EJB proxy based on these constructs. The 'cache interceptor' is something that users build in java (keep a map on the client) and vendors are building (Gemstone).

                > possible today with the AspectJ because it is
                > open-source.

                he he, really we couldn't care that it is opensource we need to relate to the technology. Please if you could do us the favor of taking the time to constrast the models above I personally would be very interested. I know Rickard Oberg would like to hear that as well in clear steps that make sense for the common man (us).

                > So this is what I see:
                > - you decided on your implementation strategy before
                > looking at the bytecode weaver

                we did, but as stressed above I am interested in knowing if it would bring something above and beyond in terms of EASE OF PROGRAMMING.

                > - you're building your AOP model from the ground up
                > as interceptors+ in XML, which is not a usable for
                > most developers except for relatively simple
                > problems

                Ok, you seem to know and understand the interceptors idea, can you please point to review or articles on the topic of AspectJ >> Indirection + interceptors and specific examples of where there are difference I believe this forum would really dig it.

                > - implement the AspectJ model, which has evolved over
                > three+ years of developer feedback about what makes
                > sense and what doesn't.

                interested in details please.

                > environment and the model. I'd be surprised if you
                > didn't get support from the AspectJ team and
                > community in following this path.

                JBoss 2 and 3 is done so really we keep the EJB container as implemented, it works well and I would rather leave it untouched.

                THAT BEING SAID.

                JBoss is early enough in its JB4 implementation that we can reasonably still switch in mid air with respect to the GENERIC framework we put forth.

                You seem to have a good understanding of the AspectJ stuff, anyone you know personally at Xerox or from the original team or the current team that would be interested in talking to us.

                > I'm psyched about JBoss doing AOP in *any* form. But
                > imho AspectJ is the best-available form and has the
                > best chance of being widely adopted, and building on
                > the AspectJ weaver is the fastest and best path for
                > JBoss to bring AOP to J2EE.

                We need specifics and examples. Please take the time to back up your claims.



                • 5. Re: Using AspectJ weaver and model
                  marc fleury Master

                  > I don't think AspectJ is the best choose for JBoss
                  > aspect implementation. imho jboss' aspect
                  > implementation looks good. there is no need for
                  > aspecj route. One comment on JBoss aspect

                  I still want to hear about the differences.

                  > implementation. the implementation should keep jboss
                  > invocation style (which is based on jmx and dynamic
                  > proxy) separate as much as possible. i think Hiram is
                  > doing pretty good job of keeping it as generic as
                  > possible and hooking jboss invocation stack throu
                  > JMXInvokerInterceptor. on the other hand instead of

                  If you read a thread in this forum on "Invokers should not be tied to JMX" you will see that Adrian makes a very valid point that essentially undoes the work I did (I was the one pushing the dynamic MBean route). Really I agree that the invoker stack should be generic with adapters to the JMX bus in case the target object is really leaving as a service in the microkernel.

                  > be generic. jboss-aspect framework proactively
                  > should be able to filter the interceptors based on
                  > method-names.

                  which we do right? did you review the XML specification of where the pointcuts are and what interceptors we weave?

                  > btw, i guess i wasn't supposed to post here as i am
                  > not jboss developer, even though i wish i could be
                  > sometime. let me know if i should post anything
                  > here.

                  jboss developer or not it is meant for developers discussions. The only thing I care is the quality of the discussions and so far this Aspect forum gets high marks on the quality. It reminds me of the early days of JBoss.

                  • 6. Re: Using AspectJ weaver and model
                    Wes Isberg Newbie

                    I think your questions are exactly right, and I'm glad
                    to see the JBoss community is wise enough to privilege
                    usability over developer interest. If/since there is already a domain-specific semantics users understand, it might be better to build on that, particularly since some find AspectJ harder to pick up or add to a development process than just sticking with Java.

                    So I will try to do that comparison, though it will be January before I can get to it. It's necessary to do a feature-level comparison with implications (e.g., instantiation, specification locality, etc.), but in the spirit of the prime directive, I'd like to hear what use cases to thought-mock in the two models. I think 1-2 should be simple enough to grok easily, and 1-2 should be hard enough that different approaches are possible within each model, and all should be the kinds of things that would make good JavaOne or customer demonstrations. Further, we should fold in some integration questions (e.g., is this controllable via JMX; how does it relate to an existing J2EE security mechanism). But all-in-all, a first cut needs to be answerable in a day or two.

                    Of course, I have to get up to speed on your model (not where it is but where it can be), and, as for working further with the AspectJ team, I will arrange some form of that.

                    Wes

                    • 7. Re: Using AspectJ weaver and model
                      Bill Burke Master

                      I am quite happy that the AspectJ guys have found JBoss. You're on the AspectJ team, right? Marc has already posted a lot of the things I wanted to say, but I have a few more comments.

                      > It is fantastic that JBoss is picking up AOP! AOP is
                      > a good antidote to much of the complexity making
                      > distributed systems hard to build.
                      >

                      Actually, JBoss has been doing AOP for years, we just didn't know that there was a specific name for what we were doing.

                      > building on the weaver. One option for your
                      > implementation is to use the AspectJ weaver as a
                      > library to implement your limited model.
                      >

                      What do you mean by weaver? Do you mean use AspectJ to implement J2EE? Or is this weaver similar to Javassist and an extension to BCEL.

                      Javassist:
                      http://www.csg.is.titech.ac.jp/~chiba/javassist/




                      > - implement the AspectJ model, which has evolved over
                      > three+ years of developer feedback about what makes
                      > sense and what doesn't.
                      >

                      JBoss has also evolved over 3 years time. We currently have 73 developers and have had over 500 developers come and go over time. We also got 2 million downloads. That being said. We have gotten by quite nicely with simple Interceptor chains both on the client and server.

                      I also used this simple Interceptor-chain approach while at Iona working on Orbix200, so you're really gonna have to convince us that the AspectJ model is the way to go.

                      BTW, PLEASE DO TRY to convince us! I really respect what the AspectJ team has done.

                      >
                      > I'm psyched about JBoss doing AOP in *any* form. But
                      > imho AspectJ is the best-available form and has the
                      > best chance of being widely adopted, and building on
                      > the AspectJ weaver is the fastest and best path for
                      > JBoss to bring AOP to J2EE.
                      >

                      My main two main beafs with AspectJ are that, one, its compiled, and two its a proprietary language. This is probably why you're seeing tons of Java-central AOP frameworks popping up everywhere. A good number of them are modeling some of your ideas which is why I hope the AspectJ team can become involved with jboss. You guys have mindshare.

                      Now, the technical reasons for why your approach is not interesting to JBoss is as follows. What I don't like about AspectJ is that it combines logic with aspect bindings. This makes it harder to do things dynamically at runtime, or programmatically introduce pointcuts and interceptions.

                      Another problem with implementing J2EE in terms of the AspectJ model is that it is Java-interface based where you have no target object to reference. This also applies to CORBA as well.

                      Finally, another thing that I believe AspectJ is missing is what I like to call the concept of "Extensions". What I mean by "extension" is the ability to attach any proprietary API to a Class (at runtime and dynamically as well.) The use case I see here is for ISVs that want to extend our EJB functionality. They would fine their own proprietary API and simply modify the aspect XML bindings to propagate it. So, an example use is:
                      {
                      EJBObject myobj = .....;
                      ISVCacheAPI cachedObj = (ISVCacheAPI)myobj;
                      cachedObj.flushCache();
                      }
                      We will be incorporating this feature into the JBoss 4 aspect framework whatever the framework turns out to be.

                      Well, in conclusing, I'm happy that you've contacted us. I truly respect the mindshare the AspectJ team has created around their software and hope that we can find some common ground so that we can leverage eachother's successes.

                      Best Regards,

                      Bill Burke
                      Chief Architect
                      JBoss Group, LLC.

                      • 8. Re: Using AspectJ weaver and model
                        Talip Ozturk Newbie

                        Bill said it all. What JBoss has been doing for years was almost AOP. AspectJ weawer (integrator) combines your java class with its aspects (which are written in a ugly javaish language). one way of doing the weawing is to run 'ajc'. ajc combines the aspects with your java classes and compiles them. there might be an api to do it at runtime but doesn't make aspectj any better. it is nice that aspectj guys picked up aop stuff very early. it is their implementation logic that fails. there is no way i can use an AOP framework that is not pure Java. IMHO fundamental requirements for an AOP framework are as follows.
                        - pure java
                        - should be able to configured via xml or java runtime-attributes
                        - runtime manipulation of aspects and interceptors.

                        jboss- keep doing what you have been doing..

                        talip

                        • 9. Re: Using AspectJ weaver and model
                          Juha Lindfors Master

                          > to say you would not use an aop framework unless it is
                          > written in 100% java is like saying i would not use an
                          > object oriented framework unless it is written in C.

                          We had this same discussion in Geneva and I agree with your point of view. If aspects do prove themselves useful then there will be an AOP language eventually.

                          I can do OOP in C but I do prefer Java for the task...

                          • 10. Re: Using AspectJ weaver and model
                            Talip Ozturk Newbie

                            timfox- thanks for very informative reply. i figured that i have been having some conceptual mistakes. now i have separated AOP techniques from AOP language. i think what i have in mind and what jboss and others (nanning, jaspect) are doing is to try applying AOP techniques to an object oriented language (in our case Java). output of such effort would be a framework with AOP techniques which is written in OOP language (java), not a AOP language.

                            IMHO, jboss-aspect or nanning's effort of applying AOP techniques is very convenient and easy for developers to get 90% of AOP if not all.

                            until the day when java syntax incorporates aop (as you said, if ever happens in coming years), AFAICT developers will want to use frameworks like jboss-aspect just because it is easy even though they might be missing (or have hacked version of) some of the 'cuts and advices' that aspectj has full support.

                            thanks for teaching

                            -talip

                            • 11. Re: Using AspectJ weaver and model
                              Tim Fox Master

                              no worries talipozturk. I'm here to learn too. :)

                              • 12. Re: Using AspectJ weaver and model
                                Bill Burke Master

                                > talipozturk - there are certain aop things that you
                                > simply cannot do directly in java - like intercepting
                                > field access.

                                Hmmmm...then how come the code I just checked into the JBoss aop framework can intercept private and protected fields? In other words, you're wrong.

                                > this is why you have to use hacks, ie byte code
                                > engineering (whether you use aspectj, bcel or
                                > javassist it is still byte code engineering), in
                                > order to fudge the effect of aop.

                                How is this fudging?

                                Bill

                                • 13. Re: Using AspectJ weaver and model
                                  Talip Ozturk Newbie

                                  private field cuts.. nice. where is that code Bill? i have
                                  jboss-all/server/src/main/org/jboss/aspect/. cvs trunk version.

                                  method and constructor cuts reasonably easy to implement. hmmmm private field cut.. tough one.

                                  it would be nice if i can check out your code..

                                  -talip

                                  • 14. Re: Using AspectJ weaver and model
                                    Hiram Chirino Expert

                                    That was my first pass at an AOP framework ala rickard style. Bill's new famework is under:

                                    jboss-aop/src/main/org/jboss/aop

                                    It's has many more features since it uses bytecode engineering.

                                    Regards,
                                    Hiram

                                    1 2 Previous Next