>From your question, I think you have the idea of the plugin. A plugin can be anything like the PersistenceManager, the InstanceCache or something as simple as a config option. They is currently a predefined list in the Container using specific set/get/create/etc. code.
By binding the plugins/config under a known name in the context, the list is no-longer hard-wired. This is already done for the ClientContainer, although the factory is still hard-wired and there is no notion of life-cycle. The stateless interceptors is a different issue. The idea here is to share interceptors to reduce memory footprint. As you said in your original e-mail, the setContainer() would still exist, it would just store state in the Invocation Context. I got that part wrong. There is no need to split out the config of an interceptor to make it stateless. 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 10:03:02 -0400 > >I don't understand the "container plugin" concept nor what it is for. > >Some interceptors, such as the security proxy interceptor (not the security >interceptor), and possibly the last interceptor that actually calls methods >on the target object, need to do extensive setup per "top of stack" >instance before they are usable. Are you proposing to make such >interceptors be split into a plugin that does the setup and the interceptor >that uses it? If so, why is this better than allowing each interceptor to >set up its own part of the invocation context when the "top of stack" >object is initialized? > >Where do things like persistence manager plugins fit into this picture? > >I'm not convinced that MBeanInvoker is a good term for the top of the stack > object. I think it is too easy to confuse with JRMP invoker etc. How >about MBeanContainer in analogy with the current ejb Container name? > >I need to think some more about the infinite regress problem. > >thanks >david jencks > >On 2002.08.01 09:06:02 -0400 Adrian Brock wrote: > > 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 > > > > > > >------------------------------------------------------- >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 _________________________________________________________________ Join the world�s largest e-mail service with MSN Hotmail. http://www.hotmail.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
