Ok marc, I'll try really hard to shut up after this one. On 2001.11.15 13:00:23 -0500 Rickard Oberg wrote: > David Jencks wrote: > > > If you pass the head of the chain with every invocation call, obviously > the > > interceptor can extract whatever metadata it needs, compute whatever > > derived info is necessary, and use it. But if these computations take > on > > the order of seconds, which is definitely a possibility and I think the > > case with the security proxy interceptor [NOT the security interceptor] > > (and the interceptor I have for rule engines), you need to precompute > the > > derived info and save it somewhere in an initialization step. No matter > > which approach we use, this initialization step is necessary. I am > saying > > that storing the results of the initialization in the interceptor makes > > more sense than putting it in an untyped map in the head of the chain. > > Doing this systematically also means you don't need to pass the head of > the > > chain when you are traversing it with a method invocation. > > > This seems to have more to do with caching than the decision on where to > keep the data. AFAICT there's no problem with caching the data in the > interceptor (although you'd have to do it in a hashtable, with the > end-point MBean name as key), to allow such initialization work to be > done. As long as you can always re-get the data from the MBean, and that > the MBean is really *in charge of* the state. > > Is the reason you want interceptors stateful only for performance? > > > >>>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. > >>> > >> > >>What if two interceptors are interested in the same metadata? > >> > > They each store the info they are interested in. If its the same as > > another interceptor, who cares? > > > Well, *how do they get that info*?? As above, if two interceptors > *cache* the data that is fine, because then they're not *in charge of* > the data from an architectural/design point of view. It is then > inherently shareable. If the metadata belongs to any of the > interceptors, then somewhere there needs to be knowledge about what > interceptor needs what metadata so that they can be provided this. In > the stateless model they are themselves responsible for accessing > whatever they need from the container (or whatever the end-point is), > thus encapsulating the knowledge of that need. > > > >>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. > >> > > > > ???? > > what I'm talking about can also be used for any container. The > metadata > > extraction occurs during chain initialization. > > > What you mean is that during chain init a particular instance is being > created for that chain. Right? What I'm saying is that interceptors > exist independently of these chains, i.e. they may exist before any > chains exist, it's just that without a chain they are never invoked. > When the chains are created particular interceptors are chosen for that > chain, and then used. Those interceptors may however be part of other > chains acting concurrently. > > > > <mbean code="org.jboss.system.InterceptorFactory" > > name="JB:service=TxInterceptor"> > > <attribute name="class">org.jboss.ejb.TxInterceptor</attribute> > > > > <mbean code="org.jboss.system.InterceptorFactory" > > name="JB:service=SecurityInterceptor"> > > <attribute name="class">org.jboss.ejb.SecurityInterceptor</attribute> > > > > <mbean code="org.jboss.system.InterceptorChainFactory" > > name="JB:service=MyChain"> > > <mbean-ref-list name="Interceptors"> > > <mbean-ref-list-element>JB:service=TxInterceptor</mbean-ref-list-element> > > <mbean-ref-list-element>JB:service=SecurityInterceptor</mbean-ref-list-element> > > </mbean-ref-list> > > > > <mbean code="org.jboss.ejb.Container" name="JB:service=example"> > > <mbean-ref name="InterceptorChainFactory">JB:service=MyChain</mbean-ref> > > <attribute name="EjbName">myEjb</attribute> > > </mbean> > > <snip> > > Excellent! Nothing like an example to clarify things. > > Here's mine: > <mbean code="org.jboss.ejb.TxInterceptor" > name="JB:service=TxInterceptor"> > <attribute name="transactionManager">java:/MyTM</attribute> > </mbean> > > <mbean code="org.jboss.ejb.SecurityInterceptor" > name="JB:service=SecurityInterceptor" > <attribute name="realm">MyCompanyRealm</attribute> > </mbean> > > <mbean code="org.jboss.system.InterceptorChainFactory" > name="JB:service=MyChain"> > <mbean-ref-list name="Interceptors"> > <mbean-ref-list-element> > JB:service=TxInterceptor > </mbean-ref-list-element> > <mbean-ref-list-element> > JB:service=SecurityInterceptor > </mbean-ref-list-element> > </mbean-ref-list> > </mbean> > > <mbean code="org.jboss.ejb.Container" name="JB:service=example"> > <mbean-ref name="InterceptorChainFactory"> > JB:service=MyChain > </mbean-ref> > <attribute name="EjbName">myEjb</attribute> > </mbean> > -- > The interceptors are MBeans, and thus configurable as MBeans. They can > have state, just as the two above does, but can also be used by any > container, and any chain. > > IMHO this is more powerful, since the interceptors can be used with > pretty much whatever MBean/endpoint. If they need info about the > endpoint, such as the TxInterceptor wanting to know whether a particular > method in the end-point has a particular tx setting, they just ask the > MBeanInfo of it, which it will get from the invocation (or at least the > end-point identifier should be in the invocation, which will allow one > to deduce the MBeanInfo from that). > > You think this is bad? Why? If it's the performance part: fine, cache it.
I think our ideas are pretty similar in most respects, and we're mostly having a difference of opinion on what is most elegant. I think the InterceptorFactory + instance/chain is elegant because the interceptor is really simple, it doesn't have to keep track of its initialization data/head, so it can type it more easily, and the chain traversal is a little simpler. I think;-) you like the "one interceptor" because, well, there's only one of them. IFAICT, the only capability that the "one interceptor" model gives you that the "interceptor factory" doesn't is the ability to change the chain while it is being traversed, and I think this is useless and haven't heard any argument. Other than that, they both have the same capabilities and it's mostly a matter of style. Thanks david jencks > > /Rickard > > -- > Rickard Öberg > > > > _______________________________________________ > 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
