When we talk about 'stateless' interceptors, do we really mean stateless, or do we merely mean stateless with regard to bean instance and client?
-danch Scott M Stark wrote: > 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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
