----- Original Message ----- From: "marc fleury" <[EMAIL PROTECTED]> To: "Rickard Öberg" <[EMAIL PROTECTED]>; "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 6:59 AM Subject: RE: [JBoss-dev] Invocation and MethodInvocation
> |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 > > afaik yes, and getting that information from the invocation pointers to the > container (container here as a repository of metadata) is a way to go. > > |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. > > yes, I agree. > Really, what am I cleaning up by moving container derived data out of the interceptors? The fact that the meta-data is in the container is simply a matter of choice. The security meta-data is really an interceptor property. No where in the codebase is the EJBSecurityManager for the container used but in the SecurityInterceptor and SecurityProxyInterceptor. The same is true of the SecurityProxyInterceptor. The custom securityProxy at the Container is also not used anywhere but in the SecurityProxyInterceptor and its supporting classes. By virtue of the fact that one can define interceptors per bean class we are supporting interceptors that are tied to their container in interceptor specific ways. Users are writing interceptors that have their own state based on data derived from container meta-data in an interceptor specific way, and the container has no knowledge of this state. > |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). > > Following Turin, the state here is really context of the state machine, > there is no context that stays with the machine once the invocation is gone > through. If there is, it is in "cache" (think EJB) not in the interceptors. > This is a restriction on the current view of the interceptors. You can argue that interceptors must be stateless. This simply pushes each stateful interceptor to develop their own session cache management layer. What are we gaining from this change in the interceptor model? _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
