On 2001.11.15 11:55:18 -0500 Rickard Öberg wrote:
> David Jencks wrote:
>
> > 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.
>
>
> Seems logical to put the MBeanInfo object of the container in the thingy
> that gets passed on. The interceptors can the extract whatever metadata
> about the container they want from that.
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.
>
>
> > 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?
>
> > 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.
????
what I'm talking about can also be used for any container. The metadata
extraction occurs during chain initialization.
>
> 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).
Lets set up an example
<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>
when the mbeans are started up, the Container gets the metadata for the
ejb, asks the InterceptorChainFactory for an interceptor chain containing
new instances of the specified interceptors from the interceptor factories,
and initializes (starts) it by sending itself or the metadata down the
chain. Each interceptor extracts whatever info it needs from the metadata
and saves it in the most convenient form in itself, in typed objects.
Method invocations go down the chain, and the interceptor instances use
their specially calculated info to do their job.
Note that the InterceptorFactory mbeans can of course include additional
attributes to further specialize the instances they create.
david jencks
>
> /Rickard
>
> --
> Rickard Öberg
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
