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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4074502#4074502
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4074502
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
