Wrong reply-to.. here it is.
--- Begin Message ---
marc fleury wrote:
> |I'll rephrase myself. Interceptors could be done as a series of JMX
> |MBeans implementing DynamicMBean, i.e. they don't do anything with the
> |call except delegate to other DynamicMBeans, with the last one actually
> |doing something. This would work, and it would make it simple to
> |configure each interceptor separately, since they're MBeans. The problem
>
> Yes this would indeed be the prefered way to work on the interceptors at run
> time.
Ok, gotcha.
> |is that for each MBean requiring a specific set of interceptors there
> |would be a bunch of additional MBeans (i.e. the interceptors
> |themselves). You would hence get loads and loads of MBeans who play the
> |interceptor game. Not sure if that's a good idea. However, if you put
>
> Not necessarily. Take for example the "transaction" interceptor in JBoss.
> It is essentially a purely stateless component so that many threads can go
> through it at once. In clear even just ONE instance of the component (Tx
> interceptor EJB semantic) is probably enough to take the full load of the
> server. I don't know enough about compiler technology to know if this is
> true or not.
It should be. So then you will instead have n number of "Tx-EJB-style"
MBeans for each configuration of it that you want to be able to use.
There is a stacking problem here though. If each interceptor is supposed
to know which interceptor comes next in the chain, then you will need
one instance per *chain configuration*. I.e. if you have two MBeans
being served by the same chain, and then want to modify the chain for
one of the MBeans, you'll have to duplicate the chain and make the
modification. It would be messy.
The only way I can see to get around that is to have the interceptor
chain interleaved with a configuration interceptor.
Example:
MBean XYZ wants the interceptor chain A,B,C (where C handles the call).
Somehow this config info is given. An interceptor stack management MBean
(MGMT) knows this, and for each incoming call the actual runtime chain
of invocations looks like this:
1. Connector.invoke (incoming call)
2. MGMT.invoke (MGMT is delegated to, and in turn delegates to first in
chain)
3. A.invoke (do the A stuff, delegate back to MGMT)
4. MGMT.invoke (determine that the chain has progressed past A, delegate
to B)
5. B.invoke (similar as 3)
6. MGMT.invoke (same as 4)
7. C.invoke (similar as 3, delegate to XYZ through reflection)
8. XYZ.invoke
9. return through interceptors
10. Connector.invoke return result
This is the only way you can get away with having a finite amount of
interceptor MBean instances. If each interceptor is aware of the next in
the chain, as in JBoss2 EJB, then you will have the config explosion
problem (i.e. each interceptor will have the state "config+chain
knowledge" instead of just "config").
See what I mean?
To get this to work the interceptor chain needs the following meta-info
in the MI:
1. Final MBean to invoke (XYZ in above case. this identifies the chain
to use)
2. Point in chain (0,1,2,3 in above case. this identifies which
interceptor in the chain to delegate to next)
3. method
4. arguments
5. custom meta-data(?)
This way you can take maximum advantage of the fact that interceptors
are largely stateless (and thread-safe), hence reusable for multiple
concurrent calls.
> Each interceptor is a state machine that works on stateless sequence of
> symbols (the MI coming through) and modify the symbols based on contextual
> information (tag declaration in tx for example).
Yes, true. As in above, the point-in-chain is very important though in
order to externalize the actual chain from the interceptors.
Agree?
> I didn't think about that before, but if you are right and we can indeed use
> the ONE dynamic MBean instead of custom stacks per bean, the we could very
> well have the mbean be the interceptors.
It would require the above to work I think, but it's definitely doable.
/R
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
--- End Message ---
