They are talking stateless with regard to any container instance. ----- Original Message ----- From: "danch" <[EMAIL PROTECTED]> To: "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 7:07 AM Subject: Re: [JBoss-dev] Invocation and MethodInvocation
> 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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
