|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.
The mbean is there to identify the target MBean for now. Whether or not we go to the "fully stateless" design might be down the road. Reread my email, for now (today's todo) it is going to point to the container. The String[] could be a String (no []) this is how I am going to use it this afternoon with the detaching of the connector (see if it works well). |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 You are mixing 2 issues, one is making the chain of interceptors fully stateless (which they are afaict I still have to see the example you are refering to). The other is list of mbeans you go through, since the interceptors AREN'T MBEANS yet, we would have to make that first wouldn't we? |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 ??? the invocation is the only one that uses the information. |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. are you benching dynamic mbeans or standard mbeans? the dynamic mbean *is* a direct method call (plus a lookup in a map, big deal). The standard mbean is a reflection call which is slow but we aren't using that as the bus. |The interceptor chain methodology I cureently think will work best involves |2 mbeans: We are NOT TOUCHING THE INTERCEPTOR CHAIN YET... we are talking about a list of MBeans. right now the only mbean is the container that was added by Scott and I wired the other day... |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 I prefer the lindfors/oberg approach to this with model mbeans. The beans will probably point to an ejb that has a persistence engine that reads xml files like the ones we have. With that you have clustered mbean configurations. I am going back to my linux box, over and out, will read stuff tomorrow/tonight, give me some time with this, we will deal with the interceptor chain when we really need to... down the road, one step at a time, professor, one step at a time. marcf |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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
