On 2002.10.03 00:29:14 -0400 marc fleury wrote: > > We've claimed for a long time that in JBoss ejb's are mbeans. > > Well, they sort of are, but the container is the mbean, and > > it calls an interceptor chain and ends up maybe doing > > something with one of a bunch of objects from a cache or pool. > > > > Meanwhile the mbeans have their own interceptor stack, with a > > slightly different interpretation of interceptor, and end up > > calling methods on a single object at the end of the stack. > > > > There's a lot of confusing functionality duplication here, > > and the interceptor incompatibilities make regular mbeans > > kind of incompetent compared to ejbs (no tx and security for > > instance). > > I think that duplication is alright.
Really? You want 2 complete sets of interceptor definititions with exactly the same functionality? > > > Here's what I propose to do: > > > > 1. change all the ejb interceptors so they only have an > > invoke method, no invokeHome. The kind of invocation is > > already carried in the invocation object, 2 methods are silly. > > that is good. > > > 2. Introduce service lifecycle into the mbean interceptors. > > I think this is best done by > > 2.a including the service lifecycle methods in the > > interceptor interface 2.b writing a lifecycle interceptor > > that fishes lifecycle methods out of the invocation stream > > and runs them through the stack. This is similar to how the > > attribute interceptor fishes attribute access messages and > > redispatches them as operations through the entire stack. > > Presumably this lifecycle interceptor (or a subclass) can > > take over the functions of ServiceContext (keeping track of > > mbean dependencies) and ServiceController (managing the > > lifecycle operations while respecting the mbean dependencies). > > negative. > > I like the idea of the invoke() being the real work of the interceptor. > I like having my hands on the chain of interceptor with methods start > and stop (by the way these lifecycle methods are already there afair > since they are container-plugins). Separating the flows of invocation > makes for easy code. You will need to code the invoke to check for the > state operations. Messy way of doing something we do VERY simply today > with a simple start() call. It is akin to saying that stopping the > assembly line is done when a "red package" goes through the stack > instead of just yelling "everybody just go home" to the whole assembly > line and shutting the power off. This will also make the implementation > of each invoke check for contents of the message and bla bla bla. We > really have no use case for this have we? > > Let's keep our invokes clean in their implementation. It won't bring ANY > feature and will just give us complex code. David, yes you can do it > but it is useless and won't be understandable. Please don't touch that > part. I have no problem not implementing (2), but I'm not sure you understand what I'm proposing since it looks to me as if you are arguing _for_ my idea. I'm proposing to make the mbean interceptors like the ejb interceptors in that they have the lifecycle methods explictly written, just like the ejb interceptors. st Several of the mbean interceptors already need the service lifecycle, they have ugly and fragile hacks since it is missing. I want to build it directly into our mbean infrastructure just as it is in our ejb infrastructure. current ejb interceptor: create start stop destroy setContainer setConfiguration setNext getNext invoke invokeHome //obsolete current mbean interceptor: getNext insert insertLast invoke proposed mbean interceptor: create start stop destroy setMBeanInvoker //not sure of name, this is like setContainer. getNext insert or setNext invoke Now, this is an mbean stack, so there needs to be something to call the lifecycle methods. It could be something in the top of the stack, but I think it is better to have a single interceptor that looks for lifecycle methods and recycles them through the stack. With this interceptor, there only has to be one thing looking for these methods. Without it, any interceptor that wants to participate in the service lifecycle has to look for itself. It looks to me as if you think my proposal will cause all the interceptors to have to look for themselves, whereas I am proposing the opposite. btw this special interceptor would I think get the ServiceContext and ServiceController functionality. Thanks for taking the time to reconsider this. david jencks > > > 3. Investigating how an mbean can work off a pool/cache of > > objects rather than a single object. This is probably just a > > deployment detail. > > > > So, > > > > Does anyone object to this? > > 1 is ok, 2 is busy code > > marc f > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
