8 Replies Latest reply on Aug 15, 2007 12:29 PM by kabirkhan

    Metadata Scope

    system.out

      Is there any way to piggybag the metadata to be accessed by other interceptors?

      I saw an example in PojoCacheImpl, but that one is applicable only within set of interceptors participating in a stack. Here I want to use the shared metadata even in different JVM.
      Here is one scenario:
      1 - client interceptor creates metadata and adds it to invocation object (assuming we have one invocation object per thread)
      2 - server interceptor looks for metadata in invocation object and updates it
      3 - another server interceptor print the information within metadata

      This should be very similar to Transaction handling in j2ee environment.

      Thanks,
      Mike

        • 1. Re: Metadata Scope
          system.out

          Any feedbacks? Apparently this is not supported in JBossaop.

          • 2. Re: Metadata Scope
            kabirkhan

            Between 1-2 is possible, we do this for EJB 3. In EJB 3 we use JBoss Remoting to send the invocation from the client to server, and make sure that the metadata is serialized with the invocation.

            For 2-3 although I have not checked properly, I believe that it should be possible to solve this by using the org.jboss.aop.metadata.ThreadMetaData class. Look for ThreadMetaData in http://anonsvn.jboss.org/repos/jbossas/projects/aop/trunk/aop/src/test/org/jboss/test/aop/basic/AOPTester.java to see how it is set up
            and see how it is transparently obtained from the invocation in http://anonsvn.jboss.org/repos/jbossas/projects/aop/trunk/aop/src/test/org/jboss/test/aop/basic/SimpleInterceptor.java

            ThreadMetaData can be found here:
            http://anonsvn.jboss.org/repos/jbossas/projects/aop/trunk/aop/src/main/org/jboss/aop/metadata/ThreadMetaData.java

            • 3. Re: Metadata Scope
              system.out

              Here is what I am looking for, excerpt from AOP_Middleware_JBoss ppt:

              "Aspects can resolve metadata dynamically
              The AOP Invocation object (ThisJoinPoint) gives hooks for this.
              Metadata can be attached to a invocation and propagated
              Aspects can pass information to one another locally or remotely
              Metadata can be overridden on a per Thread basis
              Change behavior per Thread
              Provide simple mechanism to clear all Thread metadata (Thread Pooling)
              Default values can be defined/managed per VM or per Cluster"

              Can somebody tell me how to implement it, or a link toward that?

              Thx.
              Mike

              • 4. Re: Metadata Scope
                kabirkhan

                Beyond what I posted above?

                • 5. Re: Metadata Scope
                  system.out

                  I am checking your suggestion and will provide some feedbacks soon!
                  Thanks Kabit.

                  Mike

                  • 6. Re: Metadata Scope
                    system.out

                    I am checking your suggestion and will provide some feedbacks soon!
                    Thanks Kabir.

                    Mike

                    • 7. Re: Metadata Scope
                      system.out

                      I replaced invocation.setMetaData(metadata) with
                      ThreadMetaData.instance().addMetaData(arg1, arg2, arg3) and now it is working!

                      Based on API documentation:
                      invocation.setMetaData() and invocation.getMetaData() will Set/Return all the contextual data attached to this invocation. Wondering why invocation.setMetaData() scope is different from invocation.getMetaData().

                      In otherwords, why invocation.setMetaData(metadata) doesn't do the same as ThreadMetaData.

                      • 8. Re: Metadata Scope
                        kabirkhan

                        I'm not the original author, but storing things directly in the invocation is more lightweight, you are storing in a map and don't have to store things in a threadlocal (which underlies the ThreadMetaData). The original intent for the metadata is to be "short-lived", i.e. the span of the invocations.. If you want "long-lived" metadata then you need to set it the other way, and the invocation will check whether it exists.

                        invocation.getMetaData() checks all available scopes, but at setting time you explicitly add it
                        -directly to the invocation
                        -to the ThreadMetaData
                        -to the instance advisor

                        I guess a flag could be added to setMetaData() to specify the scope, but I think it is fine as it is?

                        BTW on your server side you probably want to do something like

                        try{
                         ThreadMetaData.instance().addMetaData(...);
                         ...
                        }
                        finally{
                         ThreadMetaData.instance().clear()
                        }
                        

                        to avoid polluting subsequent threads with non-relevant metadata