4 Replies Latest reply on Apr 17, 2003 3:18 PM by marc fleury

    Rickard's AOP blog

    marc fleury Master

      Ok I was reading the rickard blog in Paris and bill wanted to defend but I said "just code" he is so beyond what we all do, the system AOP vision is extremelly clear, powerful, simple that I don't even want to put that burden of answering on him, just keep on leading I will deal with side casualties, I will deal with the blog noise, keep on koding...

      :)

      Rickard, first of all thanks for finally talking about technology, you are such a better read when you talk about tech than when you talk about people or politics. So thanks, at least it doesn't suck and we enjoy the feedback.

      Onto the points.

      1- XML mess
      nah... you invoke QDoc, we invoke XDoc, we are trailing the solid simplicity of the dotnet

      public void [simple-tag] doSomething() {}

      everything else is plagiarism and bad copy... we still don't have that at the language level, I wish we did. I hear we can embed info in the classbyte since JVM 1.0? it should simplify even your configuration file mess.

      2- the factories.
      Bill says they are in fact optional and he was just showing the XML to make it clear.

      3- J2EE security
      J2EE declarative security has well known applications and limitations. Simply securing a Pojo would enable us to simply secure JNDI for example, ala weblogic, something we failed to do back when you were in 2.0. The long rant you propose would in fact be a one one mapping with the points from Scott Stark's work in JBoss... see proxy security in JBoss from 2.4 and up and context based stuff. That is what we have and offer to AOP, meaning that the point of J2EE declarative being not enough is false in the context of JBoss

      4-. Introductions:
      I understand introductions to be instrumentation of the POJO itself. If that is the case then we are talking about that and mostly that in fact in JBOss. See cache discussion. We instrument the reference itself. We offer both modes remote needs proxy and interceptors POJO needs introduction of interceptors in the instance. something we do dynamically to the object and which is completely missing from your presentation so far. We understand the limitations of interface/DP approach very clearly (there are many others such as difficulty of recursive implementation) anyway... POJO instrumentation and the separation between class and instance is absent from what I can tell in your stuff, whereas in the cache we are writing we instrument instances dynamically through the advisable interface. Check it out beautiful work.


      5- XML indirection
      creating logical indirection is a natural step for me. I did for you in fact when you submitted the JBoss2.0 prototype, you remember that you required users to specify the container stack in XML? for every component? i did the same remark to you as I did to bill, meaning that it is OK for a prototype but for 1st iteration we need defaults. I did it for JB2.0 and JBoss2.0 was a killer product.

      OK, on the vision stuff...are you kidding?
      you are ranting about application aspects like it is something new... it is old as Bill points out something that corba mapped out already, and in fact the advisable stuff (introductions?) is something that is already in CVS and being used in system level applications by us (cache, persistence, acid). The vision is very clear... we have system aspects and a nice list of them, that enables us to offer the power of J2EE services in a dotnet like develompent framework... how powerful is that. In JB5 we will see if dynamic composition of objects is something the masses are ready for (they may be but I am not seeing the need in system right now) so I will put my money on

      future == system AOP + POJO application

      whereas you are doing

      future == POJO system + AOP application

      as far as I can read.

      I will accuse you of lack of vision my friend, Rickard is a dinausor.

      PLgAOP

        • 1. Introductions
          Bill Burke Master

          Introductions are simple:

          POJO pojo = ...;
          Cached cachedObj = (Cached)pojo;
          cachedObj.flush();

          where flush() is either delegated to an instance of an "introduced" class, or handled by an interceptor.

          IMHO, this is VERY nice feature, but basically just sexy. This feature is just not required for the system-level aspects we are writing(have written). The reason is simple. You can achieve the same idea by attaching an object to an instances (or class's) metadata. Yes, its much uglier since you have a couple levels of indirection. I will discuss in another thread how this will be implemented

          • 2. Re: Introductions
            marc fleury Master

            man this CSS sucks and the font is too small, I will fix it soon

            OK on the introductions it is the old idea of the multipleinheritance in java through DP and putting an instance to field the call.

            The system aspects are mostly detyped. That is what makes them system aspects :) the fact that they can sit in any flow of invocation an then need to expose a detyped "invoke" API. We have an API that can talk to the interface? sure big deal.

            It means Rickard is missing the usage of pojo's.

            Green light Bill, keep on doing what you are doing and let the bee-loggers bee-log. We can waste time arguing, please code.

            • 3. Re: Introductions
              Bela Ban Master

              Good work guys (Bill, that is :-)) !

              What Bill is doing with the AOP stuff reminds me of the good old days when I wrote tons of CLOS (=Common Lisp Object System) code. CLOS, like its predecessor Scheme, had the notion of a MOP (=Meta Object Protocol). It allowed you to dynamically insert functionality into a class (=Introductions).

              Seems we are getting closer to having a MOP in Java with this AOP stuff.

              We should take all the useful stuff from CLOS and apply it to JBoss (or Java in a more generic way)....

              Bela

              • 4. Re: Introductions
                marc fleury Master

                > Good work guys (Bill, that is :-)) !


                Shit man, I never get any credit here. Been busing since the 0.0 days of JBoss and other people get the credit always.

                Oh well, so is the fate of "lawrence fishburne", I find the ones, I am not the one :)