3 Replies Latest reply on Aug 29, 2005 12:53 PM by Scott Stark

    Persistence/Caching interceptors

    Ovidiu Feodorov Master

      It would be nice, and actually not only nice, but the the natural way to do it, to have a PersistenceInterceptor and a CachingInterceptor (or even a single interceptor that combines these two). However this is currently difficult to do, because the interceptor will replace the javax.jms.Message argument of the invocation with a org.jboss.messaging.core.MessageReference, and a whole set of server-side facade interfaces have to be changed.

      Maybe this is a sign that the current architecture based on server-side delegates is not the best one ...

        • 1. Re: Persistence/Caching interceptors
          Scott Stark Master

          Its important to consider whether or not the aop framework can be plugged into any service component. What can be externalized/customized via an interceptor/advise on a call path is something we need to consider if we are going to get max reuse of both existing aspects as well as the extensibility to allow for customization.

          • 2. Re: Persistence/Caching interceptors
            Ovidiu Feodorov Master

            We are already using AOP and we have a server-side AOP interceptor chain, which contains interceptors like SecurityInterceptor and InstanceInterceptor. So the framework to allow us to externalize aspects is there. I raised this issue because persistence/caching naturally belongs to an interceptor, and the current architecture doesn't allow me to do that easily, which is probably a hint that I have to change it.

            • 3. Re: Persistence/Caching interceptors
              Scott Stark Master

              Right, I would agree. I'm just pointing out that the first thing to consider is whether a given subsystem will lend its self to aop type of customizations. If it does not to some extent there needs to be a very strong performance/security type of reason.