7 Replies Latest reply on Dec 7, 2002 1:24 PM by marc.fleury

    JBoss 4.0 AOP requirements

    bill.burke

      Forgot to talk about extensions!!! See below...
      >
      > - Support POJOs (Plain Old Java Objects)
      > - Support Dynamic Proxy creation through java
      > interfaces. EJBs need this since they are
      > interface-based
      > - Support class, method, field, and constructor
      > pointcuts. If you don't already know, pointcuts
      > define an interception point.
      > - Support dynamic hot-deploy (undeploy, redeploy) of
      > pointcuts at runtime.
      > - Full integration with EJB and JMX. Meaning,
      > implement EJB and JMX in terms of AOP.
      > - Support JMX DynamicProxy creation in a simple
      > interface
      > - Interceptors should be able to be definable as:
      > "global" - One instance in entire JVM handling all
      > l pointcuts attached to this interceptor
      > "per class" - One instance per class/proxy pointcut
      > t defined
      > "per instance" - Once instance per class/proxy
      > y instance
      > - Ability to define an MBean as an interceptor and
      > reference it through the AOP XML via a ObjectName.

      - Ability to define "extensions" to dynamic proxies and classes. "Extensions" will be the ability to define a java interface that POJOs/Dynamic Proxies must "implements". A Delegate Object will receive invocations on that particular interface directly. A perfect example is the javax.ejb.EJBObject. Many methods can be serviced by the DynamicProxy without having to invoke on the Server. Another thing this will provide is the ability for ISVs to extend EJB(or anything else) with proprietary APIs(i.e. Gemstone and caching).

        • 1. Re: JBoss 4.0 AOP requirements
          bill.burke

          Forgot to talk about extensions!!! See below...
          >
          > - Support POJOs (Plain Old Java Objects)
          > - Support Dynamic Proxy creation through java
          > interfaces. EJBs need this since they are
          > interface-based
          > - Support class, method, field, and constructor
          > pointcuts. If you don't already know, pointcuts
          > define an interception point.
          > - Support dynamic hot-deploy (undeploy, redeploy) of
          > pointcuts at runtime.
          > - Full integration with EJB and JMX. Meaning,
          > implement EJB and JMX in terms of AOP.
          > - Support JMX DynamicProxy creation in a simple
          > interface
          > - Interceptors should be able to be definable as:
          > "global" - One instance in entire JVM handling all
          > l pointcuts attached to this interceptor
          > "per class" - One instance per class/proxy pointcut
          > t defined
          > "per instance" - Once instance per class/proxy
          > y instance
          > - Ability to define an MBean as an interceptor and
          > reference it through the AOP XML via a ObjectName.

          - Ability to define "extensions" to dynamic proxies and classes. "Extensions" will be the ability to define a java interface that POJOs/Dynamic Proxies must "implements". A Delegate Object will receive invocations on that particular interface directly. A perfect example is the javax.ejb.EJBObject. Many methods can be serviced by the DynamicProxy without having to invoke on the Server. Another thing this will provide is the ability for ISVs to extend EJB(or anything else) with proprietary APIs(i.e. Gemstone and caching).

          • 2. Re: JBoss 4.0 AOP requirements
            cepage

            - Full integration with new JBossMQ implementation.

            • 3. Re: JBoss 4.0 AOP requirements
              crazybob

              Are field, constructor pointcuts essential? Instrumenting methods is pretty trivial, but with constructors and fields we have to start worrying about instrumenting client code and whether or not the resulting byte code passes verification. Also, I think supporting this could justify undesirable code, i.e. "It's okay to directly access fields now," or "I don't need a factory, that's what pointcuts are for."

              Also, there's the question of instrumentation. Do we make all classes "advisable" or just the specified classes? Making a class advisable adds overhead and makes HotSpot's job more difficult; advising a method results in the creation of an object array per method invocation and extra levels of indirection.

              Lastly, another cool feature of this is that you can theoretically instrument system classes. I know that the license prohibits distributing modified system classes, but what about instrumenting them at runtime, i.e. in the build script?

              • 4. Re: JBoss 4.0 AOP requirements
                bill.burke

                > Are field, constructor pointcuts essential?

                Field definately, constructor, maybe. We want to be able to:

                - Cache POJOs transactionally and distributed.
                - Persist POJOs.

                For Cache you need to intercept field changes so that you
                know to invalidate the cache/replicate it remotely.

                Persistence is self explanatory. If you start requiring the following of an API (like get/set methods), you might as well create CMP 3.0.

                > Instrumenting methods is pretty trivial, but with
                > constructors and fields we have to start worrying
                > about instrumenting client code and whether or not
                > the resulting byte code passes verification. Also, I

                Dain Sundstrom (the CMP 2.0 lead) and I have discussed this very issue and are concerned about it. A 1st solution is to ignore it and only allow Dynamic Proxies communicating to remote aspects. A 2nd solution is to have a JBoss client-spine based on our JMX and ClassLoader scheme.

                BTW, JAC seems to get around this type of problem.

                jac.aopsys.com

                We actually tried to recruit these guys, but they are interested in creating their own app server and we will crush them.


                > think supporting this could justify undesirable code,
                > i.e. "It's okay to directly access fields now," or "I
                > don't need a factory, that's what pointcuts are
                > for."
                >

                You mean stupid users will do stupid things? That's what JBoss Group is for. Pay us $$ and we will mentor you and fix your problems :)

                > Also, there's the question of instrumentation. Do we
                > make all classes "advisable" or just the specified

                I don't think this is a problem with JBoss. JBoss has its own classloader and deployment model. We can hot-deploy anything. Regular JARS, ejbs, whatever. The way I've currently designed the 1st iteration of JBoss AOP is that if a pointcut is defined when a class is loaded, JBoss will make the class "advisable". What we could also do is when somebody hot-deploys a pointcut, cause the associated deployed jar to cycle. We have the architecture, code and infrastructure to accomplish this.

                > classes? Making a class advisable adds overhead and
                > makes HotSpot's job more difficult; advising a method
                > results in the creation of an object array per method
                > invocation and extra levels of indirection.
                >

                Yes, agreed. But I don't think this is an issue since we can redeploy classes.

                > Lastly, another cool feature of this is that you can
                > theoretically instrument system classes. I know that
                > the license prohibits distributing modified system
                > classes, but what about instrumenting them at
                > runtime, i.e. in the build script?

                Depends what you mean by system classes. The core JMX/ClassLoader/AOP framework will use a bunch of them. JAC for instance, requires you to use their system classes like Vector, Hashtable, hashmap, etc...

                Bill

                • 5. Re: JBoss 4.0 AOP requirements
                  crazybob

                  I'm convinced (easy, eh?). Let me know what you want to do, and we'll do it.

                  • 6. Re: JBoss 4.0 AOP requirements
                    miffel

                    Hi, just a few thoughts... hope you don't mind. ;-)


                    BTW, JAC seems to get around this type of problem.

                    jac.aopsys.com

                    We actually tried to recruit these guys, but they are interested in creating their own app server and we will crush them.


                    I guess you know that JAC uses load-time AOP with Javassist to create wrappers to POJOs? (They have more stuff related to their Meta-Object Protocol in the mix, but I guess that only the basic mechanism was relevant here)



                    think supporting this could justify undesirable code,
                    i.e. "It's okay to directly access fields now," or "I
                    don't need a factory, that's what pointcuts are
                    for."


                    You mean stupid users will do stupid things? That's what JBoss Group is for. Pay us $$ and we will mentor you and fix your problems :)


                    I see your points, though I would from a code beauty point-of-view eliminate field access and constructors. It's not up to me though... :-)

                    However, if you are going to support field access and constructors, I guess you are going for byte-code modification AOP, right (Javassist?)? From what I read in other entries, it was about DP's and interceptor stacks, so now I am utterly confused. I guess you will combine the two in your AOP framework, then?


                    I don't think this is a problem with JBoss. JBoss has its own classloader and deployment model. We can hot-deploy anything. Regular JARS, ejbs, whatever. The way I've currently designed the 1st iteration of JBoss AOP is that if a pointcut is defined when a class is loaded, JBoss will make the class "advisable". What we could also do is when somebody hot-deploys a pointcut, cause the associated deployed jar to cycle. We have the architecture, code and infrastructure to accomplish this.


                    This is actually my main reason for writing this entry. "When somebody hot-deploys a pointcut... " - I am curious how this works in practice.

                    Will you:
                    1) finish the currently executing control flow including the pointcut in question (think AspectJ precflow mechanism) and then hot deploy the altered/new pointcut - in other words, when the intercepted method/field/constructor is done, refresh interceptor stack

                    2) interrupt current precflow execution and make them try again using a refreshed stack (throwing and catching an exception)

                    3) finish the whole call chain from client and back again before refreshing (will all new calls get the new stack? some queueing of calls will be needed if the alteration of the interceptor stack takes time)

                    4) Other options?

                    Also, will you leave it up to the configurators of the application to choose hot-deploy method, altough some default has been set?

                    I was just hoping you could satisfy my curiosity as I have been into a discussion on run-time AOP before... Thanks in advance! :-)

                    • 7. Re: JBoss 4.0 AOP requirements
                      marc.fleury

                      > - Full integration with EJB and JMX. Meaning,
                      > implement EJB and JMX in terms of AOP.

                      I think JMX is its own beasty.

                      Other services however will really benefit from this architecture rewrite. JNDI (no-one on it yet), JMS (already started) and EJB (already done mostly).

                      > - Interceptors should be able to be definable as:
                      > "global" - One instance in entire JVM handling all
                      > l pointcuts attached to this interceptor
                      > "per class" - One instance per class/proxy pointcut
                      > t defined
                      > "per instance" - Once instance per class/proxy
                      > y instance

                      Ok I am actually very interested in that definition. I am sure it has been discussed before. I want to allow for a logical definition. Meaning define
                      class/global/instance/NAME with the scope being a logical name. This way you can support applications. I see many cases where you would want to define the pointcuts at the "application" level and not really want to define the pointcuts for all the classes in the system. With a little bit of care in the XML we could do that easily.

                      The second requirement is the reverse. Define a stack and instead of giving it a give a . Then an application or a class can refer to the assembly by name. So a component can say that he has the "standard stack" (like we define the standard entity stack for example).

                      That leads to the last point I want to make. That somehow we need independent access to the stack for runtime configuration. I think a JMX view of the stack should be done so we can come from the management mumbojumbo and do what we have to do. Let me give you an example. Changing the cache option A/B/C today requires a restart. I want to be able to come in that configuration of the stack and dynamically change it. This is something that Adrian and juha and I were talking about this summer in spain but it seems that it should be done right here in the AOP framework with MBean exposed to change attributes in a given stack.

                      > - Ability to define an MBean as an interceptor and
                      > reference it through the AOP XML via a ObjectName.