----- Original Message ----- From: "Rickard Öberg" <[EMAIL PROTECTED]> To: "Jboss-Development @ Lists . Sourceforge . Net" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 8:55 AM Subject: Re: [JBoss-dev] Invocation and MethodInvocation
> > > 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. > > > Also, a stateless interceptor can be used for any container. If you want > to just have tx's, you'd go find a tx-interceptor, and put it in the > invocation chain. The interceptor will extract the metadata it needs > about the container using the MBeanInfo, and do its work. > > If it is stateful, how will the interceptor get its metadata? I hope it > won't load it itself... that would make it dependent on the type of > object the interceptor chain is being used on (since it may be used on > things that are not EJB containers). > This is the crux of this issue. Some interceptors are stateful and are tied to the type of container they are being used with. The EJB security model is completely different than the Web security model. All the security related interceptors due is translate from the container specific model to the generic JAAS implmentation in fact. I can force a container independent model on the interceptors that show up at the top-level, but internally, the security interceptor is going to have to determine how to enforce the container specific view. Its fine to support sharing of stateless interceptors, but to say this is the only way interceptors should be handled forces a refactoring of exising usage without sufficient justification. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
