1 2 Previous Next 17 Replies Latest reply on Oct 10, 2002 2:27 PM by azakkerman

    Aspect definition, relation with interceptors

    marc.fleury

      Just so that we are clear, there seems to be quite a few definitions of "Aspect".

      Let's try to agree on what is already in CVS.

      A proxy for a client can bundle many aspects. You can attach behavior to any object by using a dynamic proxy that combines the interfaces. This is in effect multiple inheritance of *implementation* at the object level. Quite a new thing for java that dissalows this behavior by default. The same object can be cast to types that are assigned to it at runtime.

      The implementation of the aspect is achieved in a sum of interceptors. The interceptors can either be "typed or detyped". Aspect implementation = a chain of N interceptors.

      A detyped interceptor exposes the "invoke" signature and can be piped in any invocation flow for any interface in the proxy (ex security restriction in the *invocation*). These interceptors DO NOT expose an interface in the client and they add to the behavior of the list without a front end, this is totally transparent to the user (ex EJB behavior in general). One nice property of the Detyped interceptors is that the chain can DYNAMICALLY be updated. Ex: a monitoring interceptor, you can add it to the chain at run-time without disruption of the clients, we just maintain that list somewhere in our base (probably JMX MMB) and add/remove from the chain transparently to the client.

      A typed interceptor exposes a signature with an interface (think "business type"). Their power is of course the power of the typed interface, your code will work from a typed definition with clear/clean semantics. Doing a call will look like instance.doThis(withThat) and your client can interact with the aspect directly. One disadvantage is that you cannot update an aspect dynamically in the run-time. Once it is configured the instance is typed and you cannot add an interface to it. This is client disruptive. One way to work around may be to explore JDK1.4 hotswap replacement. This would really recreate a VB like environment where the type of an instance evolves in the runtime without any disruption of the client, purely hot.

      Feel free to add and complement/correct

        • 1. Re: configuration of interceptors
          marc.fleury

          REPOST FROM HIRAM

          > > Ok I imagine a client invocation chain will look like:
          > >
          > > clientproxy -> client-interceptor-stack ->
          > > serverproxy -> server-interceptor-stack -> targetMbean
          >
          > not quite there is no typed serverproxy in the middle just a straight
          > invoke() stack.
          >
          > The server/client nature just appear do to a invoker in the JBoss
          > sense.
          >

          Yeah. I forgot.. David reminded me in his email.

          >
          > so...
          >
          > > Would doing some think like this satisfy you client-server
          > > requirments? :
          > >
          > > serverproxy = factory.createAspect("server-interceptor-stack",
          > > targetMbean); clientproxy =
          > > factory.createAspect("client-interceptor-stack", serverproxy
          > > );
          > >
          >
          > so... no that would be overkill as you introduce an additional Dynamic
          > Proxy in the middle. Right now there are straight invoke().
          >

          right again.

          > The point of the separation is that you may want travelling proxies
          > and you may want inVM proxies all the time. While our client/server
          > separation works today as inVM proxies (we have the EJB proxies
          > working this way).
          >
          > It needs to be a construct in the factory whether you want
          > distributable proxies or standalone. Note that the full client/server
          > merged with no distribution would cover both cases however.
          >
          > > files. If we
          > > provide a JMX interface to the factory so that you can view/update
          > > stack configurations, would that satisfy your requirement "to have
          > > these puppies
          > > manageable."
          >
          > It is a bit more deep than that. I am really looking for a central
          > repository of that name-> configuration mapping and a way to interact
          > with it, clearly JMX is the way to go and it needs to be centralized.

          I thought thats kinda what I said. The Factory right now manages the
          name->configuration mapping. We need and uber cool JMX MBean that
          name->allows us
          to manipulate those configurations.

          > Don't worry about it for now. Bill and I are thinking about that
          > centralization. There also needs to be a callback in the interceptors
          > for configuration changes. This dynamicity of configuration is
          > completely missing from the current codebase and the EJB spec in
          > general. This would take care of that.

          You need to expand on this a little.. a small use case maybe.
          >
          > Gents I really think we got it this time. This is the end of our
          > journey... the real AOP framework in JBoss. 10 years of industry
          > dominance... a monopoly in the making
          >

          wow that gives me the tingles..

          • 2. Re: Aspect definition, relation with interceptors
            rickardoberg

            Alright, here's *my* take on what "AOP" means (this is largely the same as what's in my recent tech talks at www.java.no).

            1) Extend behaviour through interceptors. These would be the "detyped" interceptors. Logging, tx, security, "store-on-set-methods", stuff like that.

            2) Extend interfaces of the "class". An "class" in AOP can be thought of as "the set of interfaces and the set of interceptors", since objects with the same set of interfaces and same set of interceptors will "look and feel" the same.

            The base implementation is to do it using Dynamic Proxies, blah blah. You know the drill here, nothing new.

            For 1) I have (at least) the following requirements:
            *) Need to be able to replace interceptors at runtime, and especially when sending it back and forth between client and server. I want one set of interceptors on the client and one set on the server.
            *) Need to be able to specify interceptors on the "object" or on a specific interface. For example, I may want one interceptor to apply to all interfaces in a particular "class" (as defined above), and another to apply to a particular interface regardless of what "class" it is being used in. This is very very important, to have these two levels of interceptors.
            *) Need to be able to specify in descriptor (as a regular expression) what methods to apply each interceptor on. For example, I want to trigger a search engine to index my objects whenever I call a "set*|add*|remove*" method.
            *) Interceptors need to be able to be both stateless and stateful, i.e. one for all objects or one for each object.
            *) Interceptors need to be able to check what other interceptors have been run in the current execution chain, a.k.a. "wormhole".

            For 2) I have (at least) the following requirements:
            *) The interfaces should have no restrictions. No "need to extend blah" or "methods need to throw yada" stuff. Just plain interfaces
            *) My implementations need to be able to implement those interfaces directly, i.e. not like in EJB.
            *) I need to be able specify per "class" whether I want a generic implementation of an interface or if I want a particular implementation. I.e. I want to say "this class has interfaces X,Y,Z" but not *have* to say "the implementation of X is XBean". This should be provided as a default through a "the default implementation of X is XBean" declaration.
            *) I should be able to take an object, and while I'm holding on to it I should be able to attach a new interface to it that can be thrown away when I'm done. This essentially means to create a new proxy with n+1 interfaces, that has the same set of interfaces as before. Typical example of when this might be useful is if I have an object graph that I want to access through DOM: just attach DOM interfaces and send it to a XSL processor or something like that. This doesn't affect the core object model, only for how I'm using it at that particular time.

            And so on and so forth.

            I've already implemented all of this though, and yeah, it's pretty cool. If you do this in JBoss, make sure that it's not tied to JMX, or else it'll be tricky to use it in clients (e.g. we use our object model, which are AOP objects) in applets. If you can't do that, much of the value is lost.

            /Rickard

            • 3. Re: Aspect definition, relation with interceptors
              hchirino

              > 1) Extend behaviour through interceptors. These would
              > be the "detyped" interceptors. Logging, tx, security,
              > "store-on-set-methods", stuff like that.
              >
              > 2) Extend interfaces of the "class". An "class" in
              > AOP can be thought of as "the set of interfaces and
              > the set of interceptors", since objects with the same
              > set of interfaces and same set of interceptors will
              > "look and feel" the same.
              >

              yep, we have both of those right now.

              > The base implementation is to do it using Dynamic
              > Proxies, blah blah. You know the drill here, nothing
              > new.
              >

              Right.

              > For 1) I have (at least) the following requirements:
              > *) Need to be able to replace interceptors at
              > runtime, and especially when sending it back and
              > forth between client and server. I want one set of
              > interceptors on the client and one set on the
              > server.

              Do you mean: switch out the interceptor stack on an object without having to recreate the proxy object?

              > *) Need to be able to specify interceptors on the
              > "object" or on a specific interface. For example, I
              > may want one interceptor to apply to all interfaces
              > in a particular "class" (as defined above), and
              > another to apply to a particular interface regardless
              > of what "class" it is being used in. This is very
              > very important, to have these two levels of
              > interceptors.
              > *) Need to be able to specify in descriptor (as a
              > regular expression) what methods to apply each
              > interceptor on. For example, I want to trigger a
              > search engine to index my objects whenever I call a
              > "set*|add*|remove*" method.

              For the previous 2, basicly you want to filter which method calls an interceptor is used on. Not yet implemented, but doable.

              > *) Interceptors need to be able to be both stateless
              > and stateful, i.e. one for all objects or one for
              > each object.

              Right now interceptors are statless but they can attach data to the proxyObject to be able to keep state.

              > *) Interceptors need to be able to check what other
              > interceptors have been run in the current execution
              > chain, a.k.a. "wormhole".
              >

              What would it be looking for? an Interceptor[] of the previously run interceptors, or is it looking for something else (the effects of the previous interceptors?).

              > For 2) I have (at least) the following requirements:
              > *) The interfaces should have no restrictions. No
              > "need to extend blah" or "methods need to throw yada"
              > stuff. Just plain interfaces

              Yep.. thats the way it is implemented in CVS

              > *) My implementations need to be able to implement
              > those interfaces directly, i.e. not like in EJB.

              expand.. you mean the target object needs "to be able to implement those interfaces directly"? If yes, then thats how it works right now.

              > *) I need to be able specify per "class" whether I
              > want a generic implementation of an interface or if I
              > want a particular implementation. I.e. I want to say
              > "this class has interfaces X,Y,Z" but not *have* to
              > say "the implementation of X is XBean". This should
              > be provided as a default through a "the default
              > implementation of X is XBean" declaration.

              Hu?? can you expand on this?

              > *) I should be able to take an object, and while I'm
              > holding on to it I should be able to attach a new
              > interface to it that can be thrown away when I'm
              > done. This essentially means to create a new proxy
              > with n+1 interfaces, that has the same set of
              > interfaces as before. Typical example of when this
              > might be useful is if I have an object graph that I
              > want to access through DOM: just attach DOM
              > interfaces and send it to a XSL processor or
              > something like that. This doesn't affect the core
              > object model, only for how I'm using it at that
              > particular time.

              To do that now you would have to create a proxy object (with the DOM interface) to the existing proxy object. Inefficient since you'll be going through 2 proxys. It would be better if we create a new proxy that merges the interceptors.

              >
              > And so on and so forth.
              >
              > I've already implemented all of this though, and
              > yeah, it's pretty cool. If you do this in JBoss, make
              > sure that it's not tied to JMX, or else it'll be
              > tricky to use it in clients (e.g. we use our object
              > model, which are AOP objects) in applets. If you
              > can't do that, much of the value is lost.

              Nothing is tied to JMX (yet). All our stuff works on POJO. We were thinking of allowing the interceptor stacks to be configured via JMX.

              >
              > /Rickard

              Regards,
              Hiram

              • 4. Re: Aspect definition, relation with interceptors
                rickardoberg

                > > For 1) I have (at least) the following
                > requirements:
                > > *) Need to be able to replace interceptors at
                > > runtime, and especially when sending it back and
                > > forth between client and server. I want one set of
                > > interceptors on the client and one set on the
                > > server.
                >
                > Do you mean: switch out the interceptor stack on an
                > object without having to recreate the proxy object?

                If I serialize a proxy to the client it should switch interceptors, because on the client there's a bunch of interceptors that doesn't work/doesn't make sense. Same thing when serializing them back to the server. The proxies themselves are extremely transient in nature.

                It is also very important that when storing proxies in a persistent store, well you really shouldn't. What should be stored is the id of the object. Otherwise the store will blow up if the proxy definition of the object is changed, e.g. more interfaces added. If I add more interfaces to a declared "class" of objects, the ones already created and referenced in the persistent store should also, of course, get these new interfaces. This is a little tricky, but doable.

                > For the previous 2, basicly you want to filter which
                > method calls an interceptor is used on. Not yet
                > implemented, but doable.

                No, not really. The filter is easy (just match the method signature with a given regexp). The tricky part is that sometimes you want to say that "for all calls to X implementation XBean I want interceptors A,B,C. for all calls to class MyAOPClass, implementing X, I want interceptors D,E,F. Hence, when I call X.foo() on a MyAOPClass instance I want the interceptors D,E,F,A,B,C to be called, in sequence."

                > What would it be looking for? an Interceptor[] of the
                > previously run interceptors, or is it looking for
                > something else (the effects of the previous
                > interceptors?).

                It should be possible to at least:
                a) get the list of invoked interceptors, yes Interceptor[]
                b) ask for an interceptor of a specific class: getInterceptor(SomeInterceptorClass.class)

                What it does with the interceptor is use-case specific. One example that I use is to specify the persistent store as an interceptor. So, I have subclasses of PersistenceInterceptor that one can ask getPersistenceManager(). If the object needs access to its PM all it does is getInterceptor(PersistenceInterceptor.class).getPersistenceManager().

                > Hu?? can you expand on this?

                Polymorphism. I can have three "classes" with the X interface, but one "class" wants XBean impl, one wants XImpl impl, and one wants XforMyAOPClass impl. So, I need to be able to say "for this class the implementation of X is XBean", and so on. BUT the common case is that the same implementation is used, so it needs to be possible to default it, for simplicitys sake.

                > To do that now you would have to create a proxy
                > object (with the DOM interface) to the existing proxy
                > object. Inefficient since you'll be going through 2
                > proxys. It would be better if we create a new proxy
                > that merges the interceptors.

                Yes, create new is better. And for the given example you shouldn't have to "merge the interceptors" since all it is doing is adding a new interface. That is, unless you've implemented interface invocation delegation as an interceptor. Then it's trickier.

                > Nothing is tied to JMX (yet). All our stuff works on
                > POJO. We were thinking of allowing the interceptor
                > stacks to be configured via JMX.

                Good!

                And in all of this, make sure that it is SUPERFAST. If it is to be feasible to use AOP for all objects, both of "entity type" and of "session type", then the overhead needs to be as small as possible. Currently, in my own implementation the only thing that is created per-call is the Object[] array for the arguments. This is crucial, because if too much is done then it becomes too inefficient and you can't apply these things everywhere.

                /Rickard

                • 5. Re: Aspect definition, relation with interceptors
                  hchirino

                  > If I serialize a proxy to the client it should switch
                  > interceptors, because on the client there's a bunch
                  > of interceptors that doesn't work/doesn't make sense.
                  > Same thing when serializing them back to the server.
                  > The proxies themselves are extremely transient in
                  > nature.

                  So it seems like interceptor stack that should be used depends on the "context" that the proxy is being used in (client/server). The burning question is, how can proxy know what context he will be used in when he is being deserialized.

                  >
                  > No, not really. The filter is easy (just match the
                  > method signature with a given regexp). The tricky
                  > part is that sometimes you want to say that "for all
                  > calls to X implementation XBean I want interceptors
                  > A,B,C. for all calls to class MyAOPClass,
                  > implementing X, I want interceptors D,E,F. Hence,
                  > when I call X.foo() on a MyAOPClass instance I want
                  > the interceptors D,E,F,A,B,C to be called, in
                  > sequence."

                  When you talk "class" here you mean it in the AOP sense right? So you basicly want to be able use inheritance when defining your AOP classes? To reduce confusion, whey don't we call an AOP "class", an "aspect definition"?

                  >
                  > > What would it be looking for? an Interceptor[] of
                  > the
                  > > previously run interceptors, or is it looking for
                  > > something else (the effects of the previous
                  > > interceptors?).
                  >
                  > It should be possible to at least:
                  > a) get the list of invoked interceptors, yes
                  > Interceptor[]
                  > b) ask for an interceptor of a specific class:
                  > getInterceptor(SomeInterceptorClass.class)
                  >
                  > What it does with the interceptor is use-case
                  > specific. One example that I use is to specify the
                  > persistent store as an interceptor. So, I have
                  > subclasses of PersistenceInterceptor that one can ask
                  > getPersistenceManager(). If the object needs access
                  > to its PM all it does is
                  > getInterceptor(PersistenceInterceptor.class).getPersis
                  > enceManager().
                  >

                  Ok.. I like it. Adding it to my todo list

                  > > Hu?? can you expand on this?
                  >
                  > Polymorphism. I can have three "classes" with the X
                  > interface, but one "class" wants XBean impl, one
                  > wants XImpl impl, and one wants XforMyAOPClass impl.
                  > So, I need to be able to say "for this class the
                  > implementation of X is XBean", and so on. BUT the
                  > common case is that the same implementation is used,
                  > so it needs to be possible to default it, for
                  > simplicitys sake.
                  >

                  Ok.. with us you use an interceptor to add interface implementations to a AOP "class" (aspect definition). We have a stock "DelegatingInterceptor" that exposes all the interfaces of the "delegate" object (the implementation object) to the proxy. I think we might be looking at this from different angles.

                  > > To do that now you would have to create a proxy
                  > > object (with the DOM interface) to the existing
                  > proxy
                  > > object. Inefficient since you'll be going through
                  > 2
                  > > proxys. It would be better if we create a new
                  > proxy
                  > > that merges the interceptors.
                  >
                  > Yes, create new is better. And for the given example
                  > you shouldn't have to "merge the interceptors" since
                  > all it is doing is adding a new interface. That is,
                  > unless you've implemented interface invocation
                  > delegation as an interceptor. Then it's trickier.
                  >

                  ah.. yes. trickier. but doable since you will be generating a new proxy.

                  > And in all of this, make sure that it is SUPERFAST.
                  > If it is to be feasible to use AOP for all objects,
                  > both of "entity type" and of "session type", then the
                  > overhead needs to be as small as possible. Currently,
                  > in my own implementation the only thing that is
                  > created per-call is the Object[] array for the
                  > arguments. This is crucial, because if too much is
                  > done then it becomes too inefficient and you can't
                  > apply these things everywhere.
                  >

                  Our InvocationHandler creates an Invocation objet to pass down the method call + interceptor config + interceptor state down through the interceptor stack.

                  I hope this does not create a huge bottleneck.

                  Regards,
                  hiram

                  • 6. Re: Aspect definition, relation with interceptors
                    rickardoberg

                    > So it seems like interceptor stack that should be
                    > used depends on the "context" that the proxy is being
                    > used in (client/server).

                    Correct.

                    > The burning question is,
                    > how can proxy know what context he will be used in
                    > when he is being deserialized.

                    In my framework that's easy, but it depends on what the API looks like.

                    > When you talk "class" here you mean it in the AOP
                    > sense right? So you basicly want to be able use
                    > inheritance when defining your AOP classes? To
                    > reduce confusion, whey don't we call an AOP "class",
                    > an "aspect definition"?

                    Sure, that's ok.

                    > Ok.. with us you use an interceptor to add interface
                    > implementations to a AOP "class" (aspect definition).
                    > We have a stock "DelegatingInterceptor" that exposes
                    > all the interfaces of the "delegate" object (the
                    > implementation object) to the proxy. I think we
                    > might be looking at this from different angles.

                    Yeah, I was about to do that as well, but changed to having this be handled after all interceptors have been invoked. Makes it much easier to use.

                    > Our InvocationHandler creates an Invocation objet to
                    > pass down the method call + interceptor config +
                    > interceptor state down through the interceptor
                    > stack.
                    >
                    > I hope this does not create a huge bottleneck.

                    It does. Try running a simple testcase that creates a thousand objects and invoke them. How many objects are created as a side-effect of those invokes? It needs to be close to the number of invocations, e.g. as in my case only the method argument array is created. Otherwise the GC goes crazy and the whole thing will stutter badly.

                    /Rickard

                    • 7. Re: Aspect definition, relation with interceptors
                      marc.fleury

                      Rickard,

                      > Alright, here's *my* take on what "AOP" means (this
                      > is largely the same as what's in my recent tech talks
                      > at www.java.no).

                      Good to have you back.

                      > 2) Extend interfaces of the "class". An "class" in
                      > AOP can be thought of as "the set of interfaces and
                      > the set of interceptors", since objects with the same
                      > set of interfaces and same set of interceptors will
                      > "look and feel" the same.

                      Can we agree on this modelization of the Aspect.

                      [==o

                      or

                      [=-|||-=o

                      Where the front is an interface, the link the actual detyped is - and type ==

                      The o is the target object. Could be EJB, MBean, DMBean, interface + pojo, nothing.

                      The first AOP is just a simple interface+object. This is good as people like simple objects to implement their behavior, they can understand that very easily.

                      The Aspect is thus

                      [=-|||-=o
                      [==o
                      [=-|||-=o
                      [=-|||-=o

                      for example, where this interceptor has 3 detyped chains (dynamically monitorable) and 1 typed instance. We DP the whole so that the resulting Object has the 4 mentioned types.

                      An EJB for example is a simple
                      [=-|||-=o

                      Where the [ is the Remote type the = the Dynamic Proxy generated decoupler, - the detyped invoke(Invocation) signature, the |||| the interceptors implementing remoteness, transactions, CMP and cache maintenance.

                      Yes I like that, message recieved, see drawing above.


                      > The base implementation is to do it using Dynamic
                      > Proxies, blah blah. You know the drill here, nothing
                      > new.

                      Well that is actually a limitation. Let's work on BCEL for the objects and pojos. We need to be able to give an instance of anything to implement the behavior.

                      The DP bytecode would then result in the front interface showing the sum of interfaces thrown at it at construction time as well as the methods exposed by the pojos. I don't even know if this is possible in bytecode (I don't know bytecode at all).

                      > For 1) I have (at least) the following requirements:
                      > *) Need to be able to replace interceptors at
                      > runtime, and especially when sending it back and
                      > forth between client and server. I want one set of
                      > interceptors on the client and one set on the
                      > server.

                      Yes on updatability but I am fuzzy as to how you would change the client side. Right now I am thinking of an MMB to hold the interceptor configuration. Please explain how you see the client side modifications? I don't assume you want a JMX construct on the client (although we could, he he) and then how do you notify the client of the modifications? Do you allow for updates from the client? and do you allow for updates from the server? this would be simple to do in JBoss 4.0 with what bill is adding in the interfaces. In clustering we use the return value to update the topology of clients. The same could help the server control the configuration of the clients by way of the return method.

                      > *) Need to be able to specify interceptors on the
                      > "object" or on a specific interface. For example, I
                      > may want one interceptor to apply to all interfaces
                      > in a particular "class" (as defined above), and
                      > another to apply to a particular interface regardless
                      > of what "class" it is being used in. This is very
                      > very important, to have these two levels of
                      > interceptors.

                      pffff... ok here is what I want to do. I want to be able to specify for the detyped ones, what set of chains should have the interceptors. You may want "ALL" you may want "APPLICATION" you may want "OBJECT" or maybe even "METHOD" (?). This can be specified in configuration files. Kiss.

                      > *) Need to be able to specify in descriptor (as a
                      > regular expression) what methods to apply each
                      > interceptor on. For example, I want to trigger a
                      > search engine to index my objects whenever I call a
                      > "set*|add*|remove*" method.

                      do you think the following statement

                      apply CMPinterceptor where application="MY-APP" and method="get|set*";

                      uttered by a sys-admin is possible? I kinda do but I want your input on that. If not KISS, ejb-jar.xml like semantics with extensions to application.

                      > *) Interceptors need to be able to be both stateless
                      > and stateful, i.e. one for all objects or one for
                      > each object.

                      yes, I am reaching that conclusion as well. I think stateful interceptors are easier to code and configure though. Simple to do with current JBoss 3.0. The pure stateless interceptor is a theoretical possibility that is implemented in the client interceptor but whose applicability I don't really see.

                      > For 2) I have (at least) the following requirements:
                      > *) The interfaces should have no restrictions. No
                      > "need to extend blah" or "methods need to throw yada"
                      > stuff. Just plain interfaces

                      Yeah yeah yeah, we agree.

                      > *) My implementations need to be able to implement
                      > those interfaces directly, i.e. not like in EJB.

                      see my [==o object that is the one.

                      > *) I need to be able specify per "class" whether I
                      > want a generic implementation of an interface or if I
                      > want a particular implementation. I.e. I want to say
                      > "this class has interfaces X,Y,Z" but not *have* to
                      > say "the implementation of X is XBean". This should
                      > be provided as a default through a "the default
                      > implementation of X is XBean" declaration.

                      configuration. Already done in JBoss 2.x.

                      > *) I should be able to take an object, and while I'm
                      > holding on to it I should be able to attach a new
                      > interface to it that can be thrown away when I'm
                      > done. This essentially means to create a new proxy
                      > with n+1 interfaces, that has the same set of

                      You can't. A Microsoft employee who came to the Palma training pointed out that you could use hotswap in JDK 1.4 (debugging facility).

                      > interfaces as before. Typical example of when this
                      > might be useful is if I have an object graph that I
                      > want to access through DOM: just attach DOM
                      > interfaces and send it to a XSL processor or
                      > something like that. This doesn't affect the core
                      > object model, only for how I'm using it at that
                      > particular time.
                      >
                      > And so on and so forth.
                      >
                      > I've already implemented all of this though, and
                      > yeah, it's pretty cool. If you do this in JBoss, make
                      > sure that it's not tied to JMX, or else it'll be
                      > tricky to use it in clients (e.g. we use our object
                      > model, which are AOP objects) in applets. If you
                      > can't do that, much of the value is lost.
                      >
                      > /Rickard


                      ahem, where is the source?

                      marc f

                      • 8. Re: Aspect definition, relation with interceptors
                        marc.fleury

                        > Do you mean: switch out the interceptor stack on an
                        > object without having to recreate the proxy object?

                        yes that is what he means


                        > For the previous 2, basicly you want to filter which
                        > method calls an interceptor is used on. Not yet
                        > implemented, but doable.

                        how?


                        > Right now interceptors are statless but they can
                        > attach data to the proxyObject to be able to keep
                        > state.

                        yes that is the abstract Invocation view. Just keep your state in there as it is passed around. Think HTTTPSession from the servlet layers.

                        > > For 2) I have (at least) the following
                        > requirements:
                        > > *) The interfaces should have no restrictions. No
                        > > "need to extend blah" or "methods need to throw
                        > yada"
                        > > stuff. Just plain interfaces
                        >
                        > Yep.. thats the way it is implemented in CVS

                        see my answer we need more. We need to DP plain pojos. Maybe there is something in BCEL coupled with the classloaders.

                        This way we can indirect the calls as they come into our systems. I think we can make pojos DP'able this way.

                        marc f

                        • 9. Re: Aspect definition, relation with interceptors
                          rickardoberg


                          > Where the [ is the Remote type the = the Dynamic
                          > Proxy generated decoupler, - the detyped
                          > invoke(Invocation) signature, the |||| the
                          > interceptors implementing remoteness, transactions,
                          > CMP and cache maintenance.
                          >
                          > Yes I like that, message recieved, see drawing
                          > above.

                          No, that's no good, because it doesn't consider dominating interfaces and it doesn't handle object identity.

                          > Well that is actually a limitation. Let's work on
                          > BCEL for the objects and pojos. We need to be able
                          > to give an instance of anything to implement the
                          > behavior.

                          Well, sure, but then you won't get the scalability features when using this for the object model (which more or less requires an interface+impl separation, see Entity beans).

                          > The DP bytecode would then result in the front
                          > interface showing the sum of interfaces thrown at it
                          > at construction time as well as the methods exposed
                          > by the pojos. I don't even know if this is possible
                          > in bytecode (I don't know bytecode at all).

                          This is impossible, for basic Java syntactical reasons. No interfaces, no DP.

                          > Yes on updatability but I am fuzzy as to how you
                          > would change the client side.

                          If I have a User object on the server I want interceptors for server stuff, like transactions etc. I don't want these on the client, because they make no sense there. I.e. as I pass User objects back and forth between client/server/otherserver/sameserveratlaterdate the interceptor stack needs to be replaced.

                          > Right now I am
                          > thinking of an MMB to hold the interceptor
                          > configuration. Please explain how you see the client
                          > side modifications? I don't assume you want a JMX
                          > construct on the client (although we could, he he)
                          > and then how do you notify the client of the
                          > modifications? Do you allow for updates from the
                          > client? and do you allow for updates from the server?

                          That's your problem. I'm only trying to help you define the problem, not implement it. I've already implemented it in my own code, without the use of JMX (because I need it to work on clients). I don't really care what you do with this stuff. *shrug*

                          > pffff... ok here is what I want to do. I want to be
                          > able to specify for the detyped ones, what set of
                          > chains should have the interceptors. You may want
                          > "ALL" you may want "APPLICATION" you may want
                          > "OBJECT" or maybe even "METHOD" (?). This can be
                          > specified in configuration files. Kiss.

                          Not good enough. You're then missing the distinction between objects and individual object extensions. Fine, but it's an unnecessary limitation.

                          > do you think the following statement
                          >
                          > apply CMPinterceptor where application="MY-APP" and
                          > method="get|set*";
                          >
                          > uttered by a sys-admin is possible? I kinda do but I
                          > want your input on that. If not KISS, ejb-jar.xml
                          > like semantics with extensions to application.

                          Sure, that could work. Not totally seeing what the pros/cons would be compared with what I've done though.

                          > yes, I am reaching that conclusion as well. I think
                          > stateful interceptors are easier to code and
                          > configure though.

                          Depends on the API I guess. In my own AOP framework it's equally easy to write stateless/stateful, and it's just a "stateful=true" option in the XML to switch.

                          > Simple to do with current JBoss
                          > 3.0. The pure stateless interceptor is a theoretical
                          > possibility that is implemented in the client
                          > interceptor but whose applicability I don't really
                          > see.

                          *ALL* of my current interceptors are stateless. It doesn't really scale otherwise. Too many objects created if you have stateful interceptors everywhere.

                          > configuration. Already done in JBoss 2.x.

                          Oh really. Where?

                          > You can't. A Microsoft employee who came to the Palma
                          > training pointed out that you could use hotswap in
                          > JDK 1.4 (debugging facility).

                          Sure you can. That's trivial (creating a new proxy and giving it the OIH of another). Piece of cake.

                          > ahem, where is the source?

                          In our CVS.

                          /Rickard

                          • 10. Re: Aspect definition, relation with interceptors

                            > > No, that's no good, because it doesn't consider
                            > > dominating interfaces and it doesn't handle object
                            > > identity.
                            >
                            > Dominating interfaces: ???
                            >
                            > Object Identity: we do handle OID. That is what is
                            > encoded in the front interceptor and EJB interceptor.
                            > I am not sure what you mean at all. You used to be
                            > so clear rickard...
                            >

                            I think Rickard is talking about a POJO
                            that implements Runnable but later gets
                            implements Transactional

                            Runnable is the dominant interface, it should get
                            Object.toString(), etc.

                            I don't think the current Aspect implementation
                            has OID, but the EJB implementation does.

                            > > > Well that is actually a limitation. Let's work
                            > on
                            > > > BCEL for the objects and pojos. We need to be
                            > > able
                            > > > to give an instance of anything to implement the
                            > > > behavior.
                            > >
                            > > Well, sure, but then you won't get the scalability
                            > > features when using this for the object model
                            > (which
                            > > more or less requires an interface+impl
                            > separation,
                            > > see Entity beans).
                            >
                            > That is not correct. We can indirect anything these
                            > days (there is research published).
                            >
                            > > > The DP bytecode would then result in the front
                            > > > interface showing the sum of interfaces thrown
                            > at
                            > > it
                            > > > at construction time as well as the methods
                            > > exposed
                            > > > by the pojos. I don't even know if this is
                            > > possible
                            > > > in bytecode (I don't know bytecode at all).
                            > >
                            > > This is impossible, for basic Java syntactical
                            > > reasons. No interfaces, no DP.
                            >
                            > incorrect. Watch this space, I have seen it work...
                            > it is beautiful as you can indirect java system
                            > libraries.

                            Yes, it is "trivial". It is similar but subtly different
                            to the CMP Entity proxies.
                            We intercept all methods, not just abstract.
                            During classloading, we replace the concrete POJO
                            class reference in the constant-pool with
                            a dynamic proxy class reference using BCEL.

                            Thread t = new Thread();
                            now creates a DP in all POJO code loaded through the
                            classloader.

                            We can now automatically add thread pooling to
                            your code. :-)

                            >
                            > > If I have a User object on the server I want
                            > > interceptors for server stuff, like transactions
                            > etc.
                            > > I don't want these on the client, because they
                            > make
                            > > no sense there. I.e. as I pass User objects back
                            > and
                            > > forth between
                            > > client/server/otherserver/sameserveratlaterdate
                            > the
                            > > interceptor stack needs to be replaced.
                            >
                            > My question wasn't on the fact that you want
                            > different interfaces for client and server it was
                            > "how do you handle a modification of the client
                            > stack". Client gets stack A looking like [=-||-, how
                            > does he move to [=-||||-
                            >
                            > that is the question.
                            >

                            InvocationResponse invoke(Invocation invocation)
                            throws Throwable;

                            You can put what you like in InvocationResponse
                            including a new client interceptor stack.

                            Doesn't solve the DP interfaces problem.

                            The downside is another object constructed.

                            > > > Right now I am
                            > > > thinking of an MMB to hold the interceptor
                            > > > configuration. Please explain how you see the
                            > > client
                            > > > side modifications? I don't assume you want a
                            > JMX
                            >
                            > hence the MMB on the server. Client is a thornier
                            > issue (who controls that stack, how does he get the
                            > notifications from the server).
                            >
                            > > > modifications? Do you allow for updates from the
                            > > > client? and do you allow for updates from the
                            > > server?
                            > >
                            > > That's your problem. I'm only trying to help you
                            > > define the problem, not implement it. I've already
                            > > implemented it in my own code, without the use of
                            > JMX
                            > > (because I need it to work on clients). I don't
                            > > really care what you do with this stuff. *shrug*
                            >
                            > I understand that you took the client interceptor
                            > design of JBoss, glad you see the beauty of it. I am
                            > asking for feedback as to how you dynamically control
                            > the client configuration with callbacks/return (if
                            > you do). That knowledge back, if you have it, would
                            > be greatly appreciated since the client side
                            > interceptor design is Bill's idea.
                            >
                            > > > chains should have the interceptors. You may
                            > want
                            > > > "ALL" you may want "APPLICATION" you may want
                            > > > "OBJECT" or maybe even "METHOD" (?). This can
                            > be
                            > > > specified in configuration files. Kiss.
                            > >
                            > > Not good enough. You're then missing the
                            > distinction
                            > > between objects and individual object extensions.
                            > > Fine, but it's an unnecessary limitation.
                            >
                            > I don't understand your point, can you expand.

                            If I add implements Transactional, I want the
                            chain to come from the Transactional aspect.
                            I don't need the full chain for

                            ((Transactional) dp).configureMethod("java.lang.Runnable.run()", "required");

                            probably just a SecurityInterceptor.

                            >
                            > > Depends on the API I guess. In my own AOP
                            > framework
                            > > it's equally easy to write stateless/stateful, and
                            > > it's just a "stateful=true" option in the XML to
                            > > switch.
                            >
                            > statefulness is a property of the code itself,
                            > Rickard. You code your interceptor to be "stateful"
                            > in its configuration (like the 2.x server
                            > interceptors) or "stateless" like the 3.x client
                            > interceptors. Both models are interesting. I pushed
                            > stateless, I am now pretty much sure that stateful is
                            > easier to code for most people. It is not a switch
                            > though it has to do with how you code your
                            > interceptors.
                            >
                            > > *ALL* of my current interceptors are stateless. It
                            > > doesn't really scale otherwise. Too many objects
                            > > created if you have stateful interceptors
                            > > everywhere.
                            >
                            > interesting. I am not sure I buy the point (I made
                            > it on jboss-group). Sacha correctly argued that you
                            > need that configuration somewhere and there is a
                            > total equivalence between the two models, meaning
                            > that you still need an object with all the plugins
                            > and configuration so the object load is the same.
                            > Your scale point is a crock of ****. Plus
                            > scalability really comes from caches and RPC
                            > optimization as I argued at the TRIJUG (btw thanks
                            > for the blog answer, I enjoyed reading it).
                            >

                            There is obviously an overhead in the stateless code

                            Config config = (Config) invocation.getInterceptorConfig();
                            config.transactionManager.begin();

                            versus the stateful code

                            tm.begin();

                            Stateless is easier to configure, for example
                            changing a default (application level), does not require
                            updating every instance of the interceptor with the new
                            object reference.

                            Regards,
                            Adrian (An AOP newbie)

                            • 11. Re: Aspect definition, relation with interceptors
                              rickardoberg

                              > Object Identity: we do handle OID. That is what is
                              > encoded in the front interceptor and EJB interceptor.
                              > I am not sure what you mean at all. You used to be
                              > so clear rickard...

                              So each object has an Id, and if I do equals() and hashCode() I will compare with the id, right?

                              > That is not correct. We can indirect anything these
                              > days (there is research published).

                              Where can I find that research?

                              > incorrect. Watch this space, I have seen it work...
                              > it is beautiful as you can indirect java system
                              > libraries.

                              Can you outline how that would work?

                              > My question wasn't on the fact that you want
                              > different interfaces for client and server it was
                              > "how do you handle a modification of the client
                              > stack". Client gets stack A looking like [=-||-, how
                              > does he move to [=-||||-
                              >
                              > that is the question.

                              In my own system the stack is transient, so it gets set during deserialization of the DP into the client (or from database).

                              > > Not good enough. You're then missing the
                              > distinction
                              > > between objects and individual object extensions.
                              > > Fine, but it's an unnecessary limitation.
                              >
                              > I don't understand your point, can you expand.

                              An AOP "object" consists of a number of objects that have been put together to seem as one. Two such AOP "objects" may use the same partial objects. I want to be able to specify whether an interceptor should be added to a particular "object" or to a particular partial object (=extension).

                              > statefulness is a property of the code itself,
                              > Rickard. You code your interceptor to be "stateful"
                              > in its configuration (like the 2.x server
                              > interceptors) or "stateless" like the 3.x client
                              > interceptors. Both models are interesting. I pushed
                              > stateless, I am now pretty much sure that stateful is
                              > easier to code for most people. It is not a switch
                              > though it has to do with how you code your
                              > interceptors.

                              Again, this depends on the API. In my API it's the same interface that needs to be implemented (Interceptor), so it's not easier or harder to implement either.

                              Currently I have no examples of interceptors that need to be stateful, but I'm sure there will be in the future. Can you give a good example of one?

                              > interesting. I am not sure I buy the point (I made
                              > it on jboss-group). Sacha correctly argued that you
                              > need that configuration somewhere and there is a
                              > total equivalence between the two models, meaning
                              > that you still need an object with all the plugins
                              > and configuration so the object load is the same.

                              No it isn't. Let's take the transaction demarcation interceptor. The configuration is not per-object, but per-class, so I can either have 1+1 objects (conf. plus stateless interceptor) or n objects (one configured interceptor per object in the system). I'm pretty sure that the 1+1 option is going to scale better.

                              > Your scale point is a crock of ****.

                              Prove it. How does O(n) beat O(1)?

                              > Plus
                              > scalability really comes from caches and RPC
                              > optimization as I argued at the TRIJUG (btw thanks
                              > for the blog answer, I enjoyed reading it).

                              Now that is BS. You can cache all you want if each cached object is going to be huge (because of stateful interceptors). If I have stateless interceptors I'm going to be able to keep more objects in memory, given the same amount of memory. Do you disagree with this?

                              > What? A uses proxy B to talk to B' the implementation
                              > of the B front. If you change B, there is NO way to
                              > *automatically* update the B reference in A. What you
                              > are talking about is the creation of a new proxy,
                              > yeah old stuff, trivial. You don't have a way to
                              > transparently reset say a cache of such data by
                              > updating the references to the instance transparently
                              > to the application.

                              Correct, which is not what I was talking about. I was only talking about the case where I *locally* create a new proxy with more interceptors and anyone getting a reference to that proxy will get that new behaviour. Once the proxy is thrown away those changes are lost (and anyone working with the original proxy of course don't see this change).

                              > > In our CVS.
                              >
                              > kid, you are losing your edge. I can understand that
                              > you want to make some money and that you are
                              > promoting your implementation. I know for a fact that
                              > you are a genius, and real geniuses are rare in our
                              > industry. But frankly on this one, I don't know kid.
                              > Free Software communication is really what made us
                              > all progress, we are all teachers of each other.
                              > You need that feedback it seems to me as the ideas
                              > s are interesting but frankly lack clarity in their
                              > expressions.

                              You are making assumptions and guesses, and quite frankly don't know what you're talking about. Fine. You're on your own now, "kid".

                              > Time to get back on the operations table rickard...We
                              > will do a probe in your mind, see if we can save the
                              > pictures in your mind. We are good at that as you
                              > know.

                              Yes, I know.

                              Good luck.

                              /Rickard

                              • 12. Re: Aspect definition, relation with interceptors
                                marc.fleury

                                 

                                "marc fleury" wrote:
                                Welcome Adrian,


                                this is good stuff, and we are lucky to have the kid online. Sit down and pass on the left hand side will you?

                                > I don't think the current Aspect implementation
                                > has OID, but the EJB implementation does.

                                Right, I pointed that out. The OID is in interceptors though. We use the generic container with the MBeanObject and EJB with the cache idea. We support in the base invocation placeholders for both MBean and target cache. Our OID are MBean+PK, he is talking about simple PK, but in either case we already cover it in JBoss 3.0.

                                > Yes, it is "trivial". It is similar but subtly
                                > different
                                > to the CMP Entity proxies.
                                > We intercept all methods, not just abstract.
                                > During classloading, we replace the concrete POJO
                                > class reference in the constant-pool with
                                > a dynamic proxy class reference using BCEL.
                                >
                                > Thread t = new Thread();
                                > now creates a DP in all POJO code loaded through the
                                > classloader.
                                >
                                > We can now automatically add thread pooling to
                                > your code. :-)

                                precisely. Classloader is "beefed up" with bytecode injection. What I heard from Yannis (a professor at Georgia Tech) is that assigning to variables is more complex but feasable. You obviously realize how powerful this is, it means that we can know exactly what fields are accessed by the application and totally optimize the access patterns to the database. Unique.


                                > > My question wasn't on the fact that you want
                                > > different interfaces for client and server it was
                                > > "how do you handle a modification of the client
                                > > stack". Client gets stack A looking like [=-||-,
                                > how
                                > > does he move to [=-||||-
                                > >
                                > > that is the question.
                                > >
                                >
                                > InvocationResponse invoke(Invocation invocation)
                                > throws Throwable;
                                >
                                > You can put what you like in InvocationResponse
                                > including a new client interceptor stack.

                                I agree, that I how I would do it (and how we do the clustering), my question was for rickard since he claims "dynamicity" and from his answer, I understand there is none really.

                                > Doesn't solve the DP interfaces problem.

                                That one is a touchy one.


                                > > > Not good enough. You're then missing the
                                > > distinction
                                > > > between objects and individual object
                                > extensions.
                                > > > Fine, but it's an unnecessary limitation.
                                > >
                                > > I don't understand your point, can you expand.
                                >
                                > If I add implements Transactional, I want the
                                > chain to come from the Transactional aspect.
                                > I don't need the full chain for
                                >
                                > ((Transactional)
                                > dp).configureMethod("java.lang.Runnable.run()",
                                > "required");
                                >
                                > probably just a SecurityInterceptor.

                                right, but my abstract drawings allow for separate implementations of the interfaces. The current aspect implementation in CVS doesn't allow for this but the drawings I gave did. Where is the limitation.

                                > There is obviously an overhead in the stateless code
                                >
                                > Config config = (Config)
                                > invocation.getInterceptorConfig();
                                > config.transactionManager.begin();
                                >
                                > versus the stateful code
                                >
                                > tm.begin();

                                right. I in fact foresee that coded interceptors will be both at the same time. Stateless allows for the configuration to come from the 'exterior' of the interceptor and with 'dynamicity'.

                                Example: read-ahead behavior. You want the CMP engine to be local but the read-ahead to come from the client so the code will be

                                integer read-ahead = invocation.getContext().getValue("read-ahead");

                                cmpEngine.read(bla bla bla, read-ahead);

                                you get the idea.

                                > Stateless is easier to configure, for example
                                > changing a default (application level), does not
                                > require
                                > updating every instance of the interceptor with the
                                > new
                                > object reference.

                                yes see above, I think both are actually needed for powerful coding like the stuff above that knows statically what the CMP Engine is but allows for clients (who have a display of enumerations for example) to let me know how much data they want. Right now the read-ahead value is tied to the configuration when we HAVE THE CODE IN CVS TO SUPPORT THIS.

                                > Adrian (An AOP newbie)

                                You fucking kidding me? I want you as a pair on the Aspects on JBoss stuff



                                • 13. Re: Aspect definition, relation with interceptors
                                  marc.fleury


                                  > So each object has an Id, and if I do equals() and
                                  > hashCode() I will compare with the id, right?

                                  If that is your comparison yes. For example we use this construct to do the EJB equals with does id + jndi comparison.

                                  Whatever your semantic for equality of objects is you can implement.

                                  > > incorrect. Watch this space, I have seen it
                                  > work...
                                  > > it is beautiful as you can indirect java system
                                  > > libraries.
                                  >
                                  > Can you outline how that would work?

                                  see above and adrian's responses, he says it. We will put that code in CVS soon, it is way powerful for CMP applied to POJO. Do you see that? Fuck JDO, we are done kid.

                                  > In my own system the stack is transient, so it gets
                                  > set during deserialization of the DP into the client
                                  > (or from database).

                                  and therefore you do not support updates of the stack outside of a full reload. See Adrian's response as to how to do it with the return. We use that in JBoss for clustering topology updates.

                                  > An AOP "object" consists of a number of objects that
                                  > have been put together to seem as one. Two such AOP
                                  > "objects" may use the same partial objects. I want to
                                  > be able to specify whether an interceptor should be
                                  > added to a particular "object" or to a particular
                                  > partial object (=extension).

                                  which is precisely what I described in my drawing...

                                  > Currently I have no examples of interceptors that
                                  > need to be stateful, but I'm sure there will be in
                                  > the future. Can you give a good example of one?

                                  I think we are mis-communicating on the "state". State includes "configuration". Where does that configuration live is the question. Most of the current JBoss server interceptors are stateful in that respect. Most of the current JBoss client interceptors are stateless in that respect. See my point to Adrian as to why stateful/stateless is a dumb separation, both are going to be needed in something as simple as a read-ahead interceptor.

                                  > > Your scale point is a crock of ****.
                                  >
                                  > Prove it. How does O(n) beat O(1)?

                                  you are talking memory footprint, I am talking time.

                                  > > Plus
                                  > > scalability really comes from caches and RPC
                                  > > optimization as I argued at the TRIJUG (btw thanks
                                  > > for the blog answer, I enjoyed reading it).
                                  >
                                  > Now that is BS. You can cache all you want if each
                                  > cached object is going to be huge (because of
                                  > stateful interceptors). If I have stateless
                                  > interceptors I'm going to be able to keep more
                                  > objects in memory, given the same amount of memory.
                                  > Do you disagree with this?

                                  yes, totally. Scalability is about time, rickard, not memory footprint. I don't mean to give you a crash course on caches but your argument on caches even in your blog proves you don't really know what they are good for. I don't care about having more object in memory, THE WHOLE POINT IS TO HAVE THE OBJECTS IN MEMORY IN THE FIRST PLACE!!!! This gives applications a factor of 10x100 speed up AT LEAST. So you can fuck around with memory footprint it won't a bit of difference, speed up the time it gets to data and you multiply by 10 the speed, that my friend is scalability. Period. The rest is elephant spunk for architect wanker discussions.

                                  > Correct, which is not what I was talking about. I was
                                  > only talking about the case where I *locally* create
                                  > a new proxy with more interceptors and anyone getting
                                  > a reference to that proxy will get that new
                                  > behaviour. Once the proxy is thrown away those
                                  > changes are lost (and anyone working with the
                                  > original proxy of course don't see this change).

                                  right. Ok, if you control setting the references then you are set.


                                  > You're on your own now, "kid".

                                  Rickard, you know I love you. I love geniuses and you are a fucking genius. Genius doesn't mean "right all the time" it just means "above the rest". You should be happy that people like Adrian and me can see your work and say at once "back to the drawing board". We are doing this work in JBoss, most of it is in place, my dream would be that one day we get feedback on it from you directly. Don't isolate yourself, you know it is slow death of our brains. Yeah we will tell you you suck when you do and you should in fact come back here as much as you can so you can really check some of your assumptions. If you are wrong, we will tell you, who else will do it?


                                  • 14. Re: Aspect definition, relation with interceptors
                                    hchirino

                                    > > For the previous 2, basicly you want to filter
                                    > which
                                    > > method calls an interceptor is used on. Not yet
                                    > > implemented, but doable.
                                    >
                                    > how?
                                    >

                                    I've added it to CVS now.. we now ask the interceptor if he is interested in the method call before calling the interceptor. If he is not interested, we skip over that interceptor and try the next one.


                                    >
                                    > > Right now interceptors are statless but they can
                                    > > attach data to the proxyObject to be able to keep
                                    > > state.
                                    >
                                    > yes that is the abstract Invocation view. Just keep
                                    > your state in there as it is passed around. Think
                                    > HTTTPSession from the servlet layers.
                                    >

                                    Ok.. current CVS implementation uses an Object[] so that each interceptor can attach data to the DP. The advantage a Object[] has is: accessing a interceptor's attachment takes constant time. The down side is that each interceptor can only attach 1 item to the DP.

                                    Hiram

                                    1 2 Previous Next