7 Replies Latest reply on Oct 19, 2004 8:26 AM by Bill Burke

    Order of advice/interceptors - Due to: New JBoss AOP Configu

    Tomasz Nazar Newbie

      Hi,

      I was thinking about new way of specifying pointcuts, advices within a method's comment (as annotations). How do you want to order advices then? Which will be the first, and so on.. the one which classloader loads first?

      In 'jboss-aop.xml' it was simple - the same order as definition order..

      PS. In AspectJ they did it wrong. They have "precedence" keyword which must occur in one of your concerns. But if you develop few independent AOP libraries and don't want to couple them?

      E.g. "precedence: AOPConcern1, TotallyDifferentConcern2;"

      See you,
      Tomasz

        • 1. Re: Order of advice/interceptors - Due to: New JBoss AOP Con
          Kabir Khan Master

          I'm currently working on specifying things via annotations :-)

          The ordering question is a good one...

          • 2. Re: Order of advice/interceptors - Due to: New JBoss AOP Con
            Tomasz Nazar Newbie

             

            "kabkhan" wrote:
            I'm currently working on specifying things via annotations :-)


            That's why I'm trying to "warn" you before :)

            t.

            PS. I don't have idea how to solve it, in a nice manner, yet. When I get some I'll let you know..

            • 3. Re: Order of advice/interceptors - Due to: New JBoss AOP Con
              Bill Burke Master

              yes, we absolutely need precedence. I hope it gets into the initial release.

              What is your suggestion for syntax? Pure XML? A Package annotation? Per Aspect or Per Advice?

              • 4. Re: Order of advice/interceptors - Due to: New JBoss AOP Con
                andrzejkrzywda Newbie

                Hi!

                "nthx" wrote:

                PS. In AspectJ they did it wrong. They have "precedence" keyword which must occur in one of your concerns. But if you develop few independent AOP libraries and don't want to couple them?

                E.g. "precedence: AOPConcern1, TotallyDifferentConcern2;"


                I can't agree that they did it wrong. You can write an aspect which contains only precedence rules. This aspect you can use as a configuration file of your application:

                public aspect ForumConfiguration {
                 declare precedence: Security, Logging, *;
                }
                



                It doesn't couple different concerns.


                Andrzej Krzywda

                • 5. Re: Order of advice/interceptors - Due to: New JBoss AOP Con
                  Tomasz Nazar Newbie

                  Long post ..

                  "Andrzej Krzywda" wrote:
                  Hi!
                  ....
                  You can write an aspect which contains only precedence rules. This aspect you can use as a configuration file of your application:

                  public aspect ForumConfiguration {
                   declare precedence: Security, Logging, *;
                  }


                  It doesn't couple different concerns.

                  Andrzej Krzywda



                  Hi.

                  I was thinking a little about it and did some tests.

                  First you're right. That's way to achieve it in AspectJ. It could be sth similar for JBossAOP in future.

                  Second: this solution implies that a developer who uses your AOP library _must_ know AspectJ/JBossAOP syntax, etc. And this is not quite OK, and here is why I think so:

                  Imagine Jim, a developer of, say TicketsReservation system. Business logic for this world is easy and simple. He prototyped his object world with POJOs only, so he has nice running system with tests, and all of it, but these are only POJOs. He still needs persistence, transactions, GUI.
                  And now is the time for him to think about it a little bit. Of course he finds PAT for persistence ;) and some other AOP libraries for other services. But he doesn't know nothing about AOP. He's heard from a friend but didn't write any aspect. And he don't have to!
                  He wishes to annotate transactions, to annotate important business classes, _maybe_ adopt build.xml. But that should be all for him. Compilation (weaving), tests and system runs.

                  So, what I'm trying to tell in this user story, is about some developer who only wishes to use _our_ work. And it happens that our work is to develop set of services for him. And that's great and for us and for him.


                  But for now, we have a problem, with order of aspects (AOP libraries) applied which is still unsolved.
                  And I'm even not sure if Jim should know about problems with precedence at all!

                  What my idea is:existence of some known repository of known services and their precedence priorities and relations to each other. Just like /etc/services has all over the world known port numbers and names, in the same way, maybe there would exist a list of such AOP libraries. But this is only idea and I don't think if it's even realizable...

                  Another low level idea would be to give to our Jim sth like this one:
                  aopc -classpath aop-services/*.aop:$CLASSPATH$
                   -Daop.precedence=persistence,transactions
                   jim.bookingsystem.*
                  


                  In this case both libraries must not use the same annotations names of course.


                  Ok. And back to reality: there is another related problem I've discovered today.
                  I thought that with this code:
                  /**
                   * @@first
                   * @@second
                   * @@third
                   */
                   public int method1()
                   {
                   System.out.println("Method body.. :) ");
                   return 17;
                   }


                  I will get:
                  [java] ==O==[main] FirstInterceptor: 28: @first: {}
                   [java] ==O==[main] SecondInterceptor: 28: @second: {}
                   [java] ==O==[main] ThirdInterceptor: 28: @third: {}


                  But that's not the case!
                  I got
                  [java] ==O==[main] SecondInterceptor: 28: @second: {}
                   [java] ==O==[main] FirstInterceptor: 28: @first: {}
                   [java] ==O==[main] ThirdInterceptor: 28: @third: {}
                  


                  because definition of poincuts in jboss-aop.xml file was:
                  <bind pointcut="execution(* *->@second(..))">
                   <interceptor class="SecondInterceptor"/>
                   </bind>
                   <bind pointcut="execution(* *->@first(..))">
                   <interceptor class="FirstInterceptor"/>
                   </bind>
                   <bind pointcut="execution(* *->@third(..))">
                   <interceptor class="ThirdInterceptor"/>
                   </bind>


                  And I must say I don't like it.

                  As a end user (Jim) I assume that the order of advices (defined by annotations) will be the same as order of their definition in method's comment.
                  To be more verbose, I want @@securable before @@transactionable before @@persistable.

                  And as you see I prefer annotations as a way of specifying system concerns instead of "normal" poincuts definition.

                  Best regards,
                  Tomasz

                  • 6. Re: Order of advice/interceptors - Due to: New JBoss AOP Con
                    Tomasz Nazar Newbie

                    Hi!

                    I've seen some announcement of 1.0 final release of JBossAOP next week. How did you/are you going to clear things up with advice/aspect/annotations precedence?

                    Tomasz

                    • 7. Re: Order of advice/interceptors - Due to: New JBoss AOP Con
                      Bill Burke Master

                      We will work on precedence after the 1.0 release. We're currently trying to close bugs and finish documentation.