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
