Sorry, it is a confusion in terminology. The protocol specific invokers like JRMPInvoker live on the outside of the MBeanServer. There is only one of these per protocol.
Registered inside the MBeanServer are the MBeanInvokers which are as you say the "head of the stack". If the mbean is under maintenance, this is just a stub holding requests (on a timeout) until the stack, config/plugins are restarted. Some terms... The invocation is at request level. It holds info like ObjectName, "method", parameters, transaction, principal, etc. The invocation context is per mbean (with the possiblity of overrides at "method" level). It holds all the configuration. Each invocation has a pointer to the context. The interceptors pull from the invocation or the invocation's context. For example, the security interceptor asks for the method permission, which is in the InvocationContext. There is no need to setContainer() on the interceptor. This allows the method permission to be managed at runtime using the exposed MBeanInvoker and the interceptors can be shared/stateless. The method permission gets into the InvocationContext via a "ContainerPlugin". The plugins have a life-cycle and the MBeanInvoker is told about these at deployment. A simplified overview is: The container (context and interceptor stack) manages the resource (mbean/ejb). The MBeanInvoker manages the container. One of the problems is that the managed MBeanInvoker will probably need a security interceptor, you could very quickly get into recursive death if the MBeanInvokers were managed by MBeanInvokers :-) Regards, Adrian >From: David Jencks <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: [JBoss-dev] Interceptors for MBeans... TX interceptors >specifically >Date: Thu, 1 Aug 2002 08:07:02 -0400 > >What is the distinction between invocation and invocation context? Is >there a "head of the stack" as opposed to "something that accepts client >requests"? My impression of the current ejb-stack architecture is that >there are multiple invokers that attach to a single container. So, I'm not >sure if this is what you are talking about also, I think we need > >multiple invokers (probably stateless) > >head of stack object (containing all the stack instance state info, such as >which stack, what is the target object, what is the cached configuration >info the interceptors have set up for this stack) > >a stack (invocation and target object stateless, but each stack knows which >interceptors are in it) > > >the individual interceptors (stateless) > >--------- > >The security proxy interceptor has to do significant setup, therefore needs >some lifecycle. I think the xmbean attribute interceptor must also, but I >haven't looked. > >david jencks > >On 2002.08.01 05:32:09 -0400 Adrian Brock wrote: > > Hi, > > > > I was talking with Marc and Juha about this in Majorca last week. > > This is something for the 4.0 branch. > > > > The conclusion was that we have stateless interceptors with > > a model similar to what is already there for client interceptors. > > The interceptors get all there information from the invocation > > and the invocation context (which can be at either MBean or > > operation/attribute level). > > > > Inside the invocation context are the "ContainerPlugins" and > > other configuration. > > > > Sitting in front of the interceptor stack is an invoker. > > This is where the suspend()/resume() lives. > > It also exposed as an mbean for management of the invocation context, > > allowing the interceptors, plugins, commit option, transaction > > attributes, security, cache, etc. to be changed at runtime > > (assuming that part of the config doesn't require a restart). > > > > Of course, the client side container is included in this. > > > > The construction of the container will be done a factory/deployer. > > Other deployers can target it via XSLT. > > > > ejbs are one configuration of this generalised container. > > > > Question on the interceptor life-cyle. > > I can't see an example in the codebase where this is actually used. > > Perhaps I missed it? > > It doesn't make sense with shared/stateless interceptors. > > > > Regards, > > Adrian > > > > >From: David Jencks <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: [EMAIL PROTECTED] > > >Subject: Re: [JBoss-dev] Interceptors for MBeans... TX interceptors > > >specifically > > >Date: Wed, 31 Jul 2002 16:54:04 -0400 > > > > > >Well, I'd like to work on it, like, now, since I need some parts of >this > > to > > >make xsl based deployments work better. > > > > > >I think it will be workable only for xmbeans or other model mbeans. > > > > > >Steps I forsee: > > > > > >1. Make mbean interceptor stacks generated by other interceptor stack > > >factory mbeans; interceptor instances generated by interceptor factory > > >mbeans. There needs to be some boostrap interceptor stacks, perhaps > > those > > >for standard mbeans, to get this started. > > > > > >2. xmbean descriptor specifies desired stack configuration via object > > name > > >of stack factory. > > > > > >2.5?? implement a service lifecycle for mbean interceptors like the one > > for > > >ejb interceptors. > > > > > >3. ejb interceptors are converted to be mbean interceptors. I think > > this > > >mostly involves including a home/remote flag on the invocation. This > > might > > >be useful on arbitrary mbean method calls also-- home calls being > > handled > > >by interceptors for the most part. > > > > > >4. Answer the question of whether interceptors should have state as >they > > do > > >at present or be statelesss with all state info (including the > > interceptor > > >sequence) only in the invocation. > > > > > >5. convert service lifecycle management to be done by specialized > > >interceptors. > > > > > >Both interceptor models we have now answer (4) by having state in the > > >interceptor. Maybe its time to try the other way. I propose having a > > >"stack context" HashMap held in the head of the stack that the > > interceptors > > >can add stack-specific state to, keyed by themselves. > > > > > >david jencks > > > > > > > > >On 2002.07.31 15:42:06 -0400 Jason Dillon wrote: > > > > Any word on when this will be available? This is going to be a > > hugely > > > > powerful tool... especially being able to use metadata to enable > > > > different transaction semantics on MBean methods. I get all >dreaming > > > > just thinking about it... but when is that going to become a >reality? > > > > > > > > Any one know? > > > > > > > > --jason > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: Dice - The leading online job > > board > > > > for high-tech professionals. Search and apply for tech jobs today! > > > > http://seeker.dice.com/seeker.epl?rel_code=31 > > > > _______________________________________________ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > > >------------------------------------------------------- > > >This sf.net email is sponsored by: Dice - The leading online job board > > >for high-tech professionals. Search and apply for tech jobs today! > > >http://seeker.dice.com/seeker.epl?rel_code=31 > > >_______________________________________________ > > >Jboss-development mailing list > > >[EMAIL PROTECTED] > > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > > > ------------------------------------------------------- > > 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 _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com ------------------------------------------------------- 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
