Hello,
> 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.
Sure, it would be much more flexible. And an Entity container would be
"nothing more" (well almost ;) ) than an MBeanContainer (or
GenericContainer) with a specific set of plugins and interceptors)
And if the plugins could be mbeans themselves, it mean that would could add
interceptor in front of plugins, and this would be very powerful.
Regarding the "invocation", currently we can have some payload associated
with each invocation. Nevertheless, even when we do JBoss in-vm invocations,
each call is totally separated from the previous invocations. What would be
nice is to have a specific payload that persist through a sequence of
invocations (~ThreadLocal data). So we could attach data that needs to be
present through a full sequence of calls and could be used by different
interceptors of different containers, not necessarly inside the same
container.
> This is already done for the ClientContainer, although the factory
> is still hard-wired and there is no notion of life-cycle.
Well, we don't really have this concept of Plugins on the client-side. It is
a pure interceptor thing.
> The stateless interceptors is a different issue. The idea here
> is to share interceptors to reduce memory footprint.
I don't belive that. What is the wheight of an interceptor? nothing.
Furthermore, if we have purely stateless interceptor, the cost of an
interceptor is nada. You have the class bytecode once for all instances and,
for each instance, the set of fields, etc. If it is stateless, then...
Imagine: 600 different EJBs (nice application, huh ;), all having the
LogInterceptor which has, let's say 50 bytes of data. You save 30k...
I think that having stateless interceptor is more usefull because it would
allow to dynamically change (add/remove) the stack of interceptor very
easily: no real initialisation work: everything is in the invocation.
> 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.
IMHO, the setContainer should no more represent an EJB container, but just a
GenericContainer or MBeanContainer so that any application could use this
construct (ejb containers being one of them). So Container, yes, but not:
org.jboss.ejb.Container
***
Cheers,
Sacha
>
> 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
>
-------------------------------------------------------
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
