Right now we do have a number of examples of this in the form of thread local data, typically accessed via a singleton type of accessor. Converting this to a context with different scopes of data, much like the servlet attribute scoping would clean up the code. There are contexts in which this data is needed and there is no pointer to the current invocation context (background passivation of caches). So there needs to be a singleton accessor that allows one to hook into the scoped context data at the call/thread level.
> > Regarding the "invocation", currently we can have some payload associated > with each invocation. Nevertheless, even when we do JBoss in-vm invocations, > each call is totally separated from the previous invocations. What would be > nice is to have a specific payload that persist through a sequence of > invocations (~ThreadLocal data). So we could attach data that needs to be > present through a full sequence of calls and could be used by different > interceptors of different containers, not necessarly inside the same > container. > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
