-
1. Re: Metadata Scope
system.out Aug 15, 2007 9:57 AM (in response to system.out)Any feedbacks? Apparently this is not supported in JBossaop.
-
2. Re: Metadata Scope
kabirkhan Aug 15, 2007 10:15 AM (in response to system.out)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 Aug 15, 2007 10:16 AM (in response to 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 Aug 15, 2007 10:17 AM (in response to system.out)Beyond what I posted above?
-
5. Re: Metadata Scope
system.out Aug 15, 2007 11:32 AM (in response to system.out)I am checking your suggestion and will provide some feedbacks soon!
Thanks Kabit.
Mike -
6. Re: Metadata Scope
system.out Aug 15, 2007 11:33 AM (in response to system.out)I am checking your suggestion and will provide some feedbacks soon!
Thanks Kabir.
Mike -
7. Re: Metadata Scope
system.out Aug 15, 2007 12:12 PM (in response to 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 Aug 15, 2007 12:29 PM (in response to system.out)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 liketry{ ThreadMetaData.instance().addMetaData(...); ... } finally{ ThreadMetaData.instance().clear() }
to avoid polluting subsequent threads with non-relevant metadata