8 Replies Latest reply on Dec 16, 2002 1:54 PM by marc.fleury

    New Direction for JBoss AOP

    bill.burke

      Code is under jboss-head/aop

      It compiles but that's about it. Its incomplete.

      The new direction is shown in the below xml if you can follow along. Don't have much time for explanation before Thanksgiving, but the idea is POJOs and DynamicProxies married into one framework. Field access, Constructors and methods interceptable on POJOs. More funtionality can be inferred if you read the following XML.

      <!-- Interceptor definition. This is just a template
      "name" is the string reference to the interceptor
      "classname" is its classname
      "scope" defines how the interceptor is instantiated
      instance - one interceptor instance per object instance
      class - one instance per class
      global - one instance for entire VM

      config - defines any arbitrary xml to pass to component for initialization
      -->


      </interceptor-service>


      <!-- Extensions are classes that can be attached to an object to provide
      extended APIs.

      "name" is the string reference to the extention
      "classname" is its classname
      "scope" defines how the extension is instantiated
      instance - one extension instance per object instance
      class - one instance per class
      global - one instance for entire VM

      interfaces - are a list of interfaces to extend the aspected object.
      Any methods invoked on the aspect that pertain to these
      interfaces will be delegated directly to the extension class
      config - defines any arbitrary xml to pass to component for initialization


      i.e.
      Class MyClass {}

      interface api { void doSometing(); }

      Class MyExtension implements api { public void doSomething(){ ... } }


      You could do in code
      {
      MyClass instance = new MyClass();
      api a = (api)instance;
      a.doSomething();
      }
      Even though MyClass doesn't implement the api interface, or has the code for it
      you can cast and invoke on it anyways. This is the extension.
      -->
      <extension name"extension1" classname="" scope="instance,class,global">




      <!-- chain of interceptor definition -->

      <interceptor-ref name="service1"/>





      <!-- interceptor pointcut defines what classes, methods,fields must be intercepted
      and by what -->
      <interceptor-pointcut name="" class=".*pattern*">
      <method-pointcut expr="*set*/>
      <!-- Don't intercept method defined in these interfaces -->
      <method-pointcut>
      <excluded-interfaces/>
      </method-pointcut>

      <!-- Intercept methods defined in all these interfaces -->
      <method-pointcut>
      <included-interfaces/>
      </method-pointcut>

      <field-pointcut expr="*variable*"/>
      <field-pointcut expr="{PUBLIC,PRIVATE,PROTECTED}"/>


      <stack-ref name="stack1"/>
      <interceptor-ref name="">

      </interceptor-ref>

      </interceptor-pointcut>

      <!-- Extension pointcut defines what classes should be extended -->
      <extension-pointcut name="" class=".*">

      <extension-ref name="extension1"/>


      </extension-pointcut>

      <!--
      A proxy is a template for creating Dynamic Proxies.

      -->


      <interceptor-pointcuts/>



      <!--
      Add a pointcut to created proxy
      -->
      <interceptor-pointcut name="" proxy="">
      <method-pointcut>
      <included-interfaces/>
      </method-pointcut>

      <stack-ref name="stack1"/>
      <interceptor-ref name="">

      </interceptor-ref>

      </interceptor-pointcut>




        • 1. Re: New Direction for JBoss AOP
          hchirino

          Hi Bill,

          the new AOP stuff seems to be very Classloader dependent. How will it work in a client-side environment (say an applet) where the classloader structure cannot be readily controlled??

          Regards,
          HIram

          • 2. Re: New Direction for JBoss AOP
            bill.burke

            > Hi Bill,
            >
            > the new AOP stuff seems to be very Classloader
            > dependent. How will it work in a client-side
            > environment (say an applet) where the classloader
            > structure cannot be readily controlled??
            >
            > Regards,
            > HIram

            If we want to intercept field access, constructors and methods for a regular POJO class, we will have to have control of the classloaders. How else will we do it? You could do a compilation approach, but I think we want to avoid this. Plus the POJO framework should be pluggable enough in that you could get your class definitions either way, compilation or classloader.

            • 3. Re: New Direction for JBoss AOP
              hchirino

              As we have been discussing in other threads, the compilation approach has many down-sides. Here's an idea that I think has been used by jboss before:
              Have jboss provide a URL that can be used as the codebase for an applet.

              use case:
              (1) developer creates a game-applet.jar
              (2) He deploys the game-applet.jar with some aop metadata that says the AOP version of game-applet.jar should be accessible at say http://localhost:8080/game-applet.jar-codebase/
              (3) the applet would load classess from that url. eg: http://localhost:8080/game-applet.jar-codebase/com.foo.GameApplet.class

              I guess we can do this with applets cause they use URLCLassloaders. But what about a normal java app?? How are we going to hijack the classloader to use AOP classes?

              Regards,
              Hiram

              • 4. Re: New Direction for JBoss AOP
                bill.burke

                > As we have been discussing in other threads, the
                > compilation approach has many down-sides. Here's an
                > idea that I think has been used by jboss before:
                > Have jboss provide a URL that can be used as the
                > codebase for an applet.
                >
                > use case:
                > (1) developer creates a game-applet.jar
                > (2) He deploys the game-applet.jar with some aop
                > metadata that says the AOP version of game-applet.jar
                > should be accessible at say
                > http://localhost:8080/game-applet.jar-codebase/
                > (3) the applet would load classess from that url.
                > eg:
                > http://localhost:8080/game-applet.jar-codebase/com.fo
                > .GameApplet.class
                >
                > I guess we can do this with applets cause they use
                > URLCLassloaders. But what about a normal java app??
                > How are we going to hijack the classloader to use
                > AOP classes?

                In JDK 1.4.x can't you define the class for the SystemClassloader?

                • 5. Re: New Direction for JBoss AOP
                  bill.burke

                  After reading some of Rickard's Blogs and thinking how we will add transactions, security, persistence, here's some additional XML to define Metadata on class methods and fields.



                  Required


                  <!-- overrides previous wildcard -->

                  RequiresNew



                  true
                  true





                  [Edited by: Bill Burke on Dec 14, 2002 12:37 PM]

                  • 6. Re: New Direction for JBoss AOP
                    hchirino


                    > > How are we going to hijack the classloader to use
                    > > AOP classes?
                    >
                    > In JDK 1.4.x can't you define the class for the
                    > SystemClassloader?

                    I don't think so. 1.4 allows you to add jars to the boot classpath. I don't think that helps us with our problem. We need a good solution this since AOP on the client side is a BIG requirment for our AOP framework.

                    Regards,
                    Hiram

                    • 7. Re: New Direction for JBoss AOP
                      dsundstrom

                      Bill,

                      I think we should support a factory attibute instead of the classname. We may want to return different implementation if an interceptor based on the configuration. For example, if the EntitySynchronizationInterceptor has the multi-instance element set to true, we would return the EntityMultiInstanceSynchronizationInterceptor instead. This could really reduce the number of container configurations.

                      Do you have an example of the complete XML? I would be helpful to see an exmaple complete configuration. Thanks.

                      -dain

                      • 8. Re: New Direction for JBoss AOP
                        marc.fleury

                        > Bill,
                        >
                        > I think we should support a factory attibute instead
                        > of the classname. We may want to return different

                        I disagree on the instead. Don't design by exception. Frankly having the classname is simple. Very simple and intuitive so don't go with a "factory". If there are cases where you absolutely NEED a factory (I can't really see them) then put that as an override where you specify the factory class (and how does the factory know the class? yet another indirection). So for now drop this and add it yourself when you REALLY see an exceptional case that should be treated.