Any of the interceptors can be made stateless, its a question of the cost of reassociating the state from the container meta-data and having to cast from an opaque generic form to the data required by the interceptor. The current state in the security interceptors is just cached data derived from the container meta-data. In the case of the SecurityProxyInterceptor the derived data can be an expensive transformation of the container meta-data. > > > |should not need to know or store the interceptor-specific state info for > > |its chain. IMHO using a catch-all (or cache-all) map is a bit of a hack. > > |In particular, this conflicts directly with the security proxy interceptor. > > > But isn't the state that the security interceptor uses really meta-data > about the container? Shouldn't the interceptors get all meta-data from > the *container*? If that is done, you'd get very clean separation of > concerns, where the interceptor act upon the meta-data, but is not > responsible for the actual meta-data. To me that seems more natural. > > So, the point isn't that the security interceptors should be stateless. > In fact, they may very well be stateful. However, they should not have > state *particular to any one container* (compare with Stateless Session > Beans). >
_______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
