then you are on top of it David? go ahead kid!
marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Tuesday, October 02, 2001 11:13 AM |To: jboss-dev |Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ |[[EMAIL PROTECTED]] | | |Grr, can someone set the reply to back to the list? I sent this originally |just to Rickard. I'm reposting because of the comments about mbean config: |lots of people suggested the iterator by now. | | |On 2001.10.02 10:09:01 -0400 David Jencks wrote: |I'm not sure if this is the same as what you guys are suggesting: | |The interceptor mbeans don't need to know who they are connected to in the |invocation chain. | |The top of the stack (connector?) does - it has an (ordered) list of the |interceptors it uses. | |A MI coming in gets an iterator on that list from the top of the stack |(connector?) | |When an interceptor is done is asks the iterator in the MI where to go |next. | |A slightly more concrete implementation of this has the list at the top be |a linked list, and the "iterator" in the MI be a pointer into this linked |list. | | |So... in terms of configuration we have: | |each interceptor configured separately as mbean | |Each interceptor stack configured as an mbean with a list of the |interceptor mbeans it uses. | |If we do this with xml configuration, I think we now have 3 kinds of mbean |attributes: | |plain (like we have now) |mbean reference/dependency (replaces depends) |list (for interceptor stacks at least) | | |david jencks | |On 2001.10.02 04:00:19 -0400 Rickard Öberg wrote: |> marc fleury wrote: |> |> > We would create the interceptors independently of each other. And then |> > "creating a stack" is nothing more than instructing incoming gates |> (.net, |> > rmi, whatever) that the messages requesting "EJB-style" fielding should |> go |> > through this stack of ObjectName interceptors. standardjboss.xml needs |> to |> > map one on one there. |> |> |> Well, the only thing the incoming gates would have to know is to |> immediately delegate to the stack configuration MBean. After that it can |> take care of the stack config. |> |> *But this will only work if the interceptor/config interleaving is done |> as outlined in previous post*. Otherwise it will be an MBean explosion... |> |> |> > The stack of state machines, the movie seen by the MI, is a random |> access |> > stack from the point of view of the admin. |> > |> > Then updating the flow means talking to that "route mapper" at the |> gates. |> |> |> Which, as discussed, need to be hand-holding the MI as it travels along |> the stack. |> |> |> /R |> |> |> -- |> Rickard Öberg |> Software Development Specialist |> xlurc - Xpedio Linköping Ubiquitous Research Center |> Author of "Mastering RMI" |> Email: [EMAIL PROTECTED] |> |> |> _______________________________________________ |> 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
