wowowo, I realize I forgot to say what this is good for :)
you can now attach ANY PAYLOAD to an invocation, not just the stuff generated at the client, so that you can pass information down the chain, have interceptors talking to each other and pass arbitrary data around the JMX base, VERY VERY VERY useful for your custom advanced interceptors. (was it the motorola kids in the Las Vegas training that mentioned they needed this?) marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Wednesday, November 14, 2001 12:08 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: [JBoss-dev] Invocation and MethodInvocation | | |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
