|When we talk about 'stateless' interceptors, do we really mean |stateless, or do we merely mean stateless with regard to bean instance |and client?
bean instance and client marcf |-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
