On 2002.10.03 02:00:12 -0400 Scott M Stark wrote: > > > > > 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.
I'm not sure if I want to completely remove ServiceController. I do want the ServiceProxy to be part of the final interceptor on the chain, calling methods on the actual managed object. The lifecycle calls always need to get to the interceptors so the mbean stack is set up properly, whether or not the managed object needs them. I want to remove the current anomoly that calling say start on an mbean directly bypasses the dependency checking whereas calling ServiceController.start(mbeanName) does the dependency checking. Putting the ServiceContext and dependency checking code in an interceptor will do this. > > What does the generalized container, metadata, and factories look like? I don't know yet, I have to do this one step at a time or I get confused. david jencks > > > > ------------------------------------------------------- > 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
