This is great. This is what I wanted to do when I wrote my "message" passing hack. I think one problem is the current interceptors will be expecting a Method object, so when they are changed to handle an Invocation with out a Method object, I will definitely switch over.
-dain > -----Original Message----- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 14, 2001 11:44 AM > To: marc fleury; Jboss-Development@Lists. Sourceforge. Net > Subject: RE: [JBoss-dev] Invocation and MethodInvocation > > > 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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
