Although I originally thought including an mbean-iterator in the method invocation, as you have done, was the way to go, after discussion with Scott and some experiments I changed my mind to think an approach using interceptor factories and interceptor chain factories (both mbeans) is a better idea.
There are 2 problems I know of with the mbean-iterator approach. 1. It requires the interceptors to be stateless. All state info has to be carried in the invocation object. Any setup information the interceptor may need has to be stored in the head-of-the-chain object and sent with each MI. IMHO this is _really_ not where this info belongs. The head should not need to know or store the interceptor-specific state info for its chain. IMHO using a catch-all (or cache-all) map is a bit of a hack. In particular, this conflicts directly with the security proxy interceptor. 2. (possibly an implementation issue, but real at the moment). Calling mbeanserver.invoke is _wayyyy_ slower than a direct method call. On my machine, 100,000 iterations in 10 sec compared with 0 sec. I think this will be a significant performance problem. There is one possible advantage: 1. The Invocation might be able to recompute its mbean-list on the fly. However, I'm less than convinced that supporting this is a good idea. I think if someone tried to use it they would just get confused for no good reason. The interceptor chain methodology I cureently think will work best involves 2 mbeans: Interceptor factories: takes Interceptor class name as an attribute, has an mbean method newInterceptor returning a copy of the Interceptor. This is a dynamic mbean, it could be made to expose the get/set properties of the interceptor as attributes in the InterceptorFactory mbean. InterceptorChainFactory: takes an mbean-ref-list of the mbeans you want in the chain. Has a newInterceptorChain method taking the head and tail of the chain as parameters, returns a new chain with the interceptors specified in the list. Calls init(head) on each interceptor. (the head is an object that is assumed to contain the info needed for initialization, such as the info for the SecurityProxy setup.) The supplied tail is setup as the last element. I have this much written. I have been wondering how to fit this into the ContainerFactory: I think one approach might be to make the Containers into MBeans that can be configured as any other mbeans in a service-xml file, and include an mbean-ref to the InterceptorChainFactory needed. The ContainerFactory could have mbean-refs to the default chains for each type of bean. I haven't looked into this extensively yet. Thanks david jencks On 2001.11.14 12:08:00 -0500 marc fleury wrote: > Ok, > > [FOR RECORD, ARCH CHANGE] > > we discussed some time ago the possible extension of the > "MethodInvocation" > to be a more generic and powerful entity. > > Basically I have added the invocation directory and the Invocation.java, > as > well as changed the MethodInvocation. > > The 10,000 ft is that the new RH JMX view puts the mbeans in front. The > entity that travels inside our JMX bus is the "Invocation" that I just > introduced. The invocation basically takes the transaction and security > information as its basis. You are always doing stuff as part of > transaction > context (maybe empty meaning no transaction) and as someone authenticated > (if you set it up) but these are the building blocks. Then everything > else > is in a "payload" of possibly serialized byte[] data that we can carry > around as such (avoiding cl madness). We extend this for the > methodinvocation which is more EJB'ish in that it knows about the > EnterpriseContext (more on that later). > > The other new thing in there is the presence of the mbean list of objects > this Invocation is supposed to go through. It will identify the MBean > interface of the Container for the EJBs, thereby really finalizing the > detaching of the invokers from the invocation, both from the bus (which > is > already done) and the rmi impl (to be done next). > > The Invocation is not using the mbean list as yet, but possibly will, > since > what would come next is a self standing "invocation" in our JMX base, > going > through the bus from mbean to mbean, which would really give us a > possibly > dynamic way of maintaining the path that our invocation takes in the > base. > The stuff is there, will use a little bit to hook up the EJB container, > we > will see. > > I will also probably don't externalize the interceptors as yet, no good > reason except it would be less disruptive a view from what we have now > and > it would be lindfors recommendation. > > I was going to talk about the "EnterpriseContext" thing but this is > already > a long mail. I will do so in a forthcoming email. > > Finally I will say that for legacy reasons I have kept the old > constructors > and allowed the Invocation to carry no MBean association. The 2 legacy > are > 1- the invocation chain is not fully generic yet, it knows the target, > this > is detached already (going JMX bus) but will move next 2- the CMR stuff > from > Dain that uses the invocation chain to invoke stuff on itself, this > assumes > that you know the container (which it does) and calls it directly (which > it > does) withouth the intermission of the JMX bus (which is ok), so this is > likely to remain as is for now. Moving it to the bus would be trivial but > not a priority right now. > > The testsuite testbean runs fine afaict, so this should not disrupt the > existing RH codebase, fully backward compatible (again afaict) > > just warming up > > marcf > xxxxxxxxxxxxxxxx > Marc Fleury > President > JBoss Group, LLC > xxxxxxxxxxxxxxxx > > > _______________________________________________ > 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
