> 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. > 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. > 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
