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.
/Rickard
--
Rickard Öberg
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
