> > Really? You want 2 complete sets of interceptor definititions with exactly > the same functionality? I don't. The whole ejb interceptor layer should be deprecated if not replaced in 4.0.
> > > 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. Agreed. > > 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. > I don't see the need to throw away the ServiceController here. Rather, the Service proxy is what calls the lifecycle methods. When the controller calls create on the proxy it invokes create through the stack and ultimately this is invoked on the mbean. The same for all the other life cycle methods. What does the generalized container, metadata, and factories look like? ------------------------------------------------------- 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
