On 2001.11.15 11:09:40 -0500 Scott M Stark wrote: > I feel like its deja vu all over again. About a month ago I had this same conversation with Scott and concluded that having an instance of interceptor for each chain is definitely the way to go. Here are some reasons:
Whether you put the state in the interceptor instance or the head of the chain, you need the same state info. If you put it in the head of the chain, you either have to put instance variables specific to the interceptors that will be in the chain if you want any compiler type checking help or use an untyped map and hope for the best if you want it generic. If you put the state info in the interceptor instance, you can have all the compiler type checking you can stand, you keep the state info needed for the interceptor encapsulated in the interceptor (where, I will say, it belongs), and the interceptor becomes much more self contained. I vote for instances of interceptors per chain. The only feature the stateless approach gets not easily available with the statefull approach is the ability to change which interceptors are called during the chain traversal. I don't see any use for this meta-meta programming at this time. david jencks > ----- 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
