|-----Original Message-----
|From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
|Sent: Wednesday, November 14, 2001 4:13 PM
|To: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|
|
|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.
it is already done, the new "MI" walking down supports the addvalue and
getvalue... go ahead use it!
marcf
|
|-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
