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
