cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 16:23:36 GMT
> From: Vadim Gritsenko [] 
> > Furthermore, a GeneratorManager can declare its own 
> semantics.  If you 
> > want the release() method there, then there are no issues 
> conflicting 
> > with overall CM design.
> Ok, it means that for Generator I should create 
> GeneratorManager, and for XXXXX - XXXXXManager.


> > > I think discussion here was carried away from topic... 
> Architecture
> of
> > > future Cocoon should be discussed separately. I was 
> trying only to 
> > > clarify how container will handle absence of the release() method.
> > 
> > The GeneratorManager would handle the release() method, or it would 
> > declare its semantics for use.
> > 
> > Component use should not be a function of component lookup.
> Ok. What then will be contract between component manager and 
> user? When you call lookup(), what should you expect - 
> Component, ComponentSelector, ComponentGenerator, Pool, 
> something else?
> Or, I always will get XXXXXManager? Then, lifecycle 
> management will be moved to XXXXXManager, right?

You will always get the XXXXXManager.  So yes, lifecycle does
move to XXXXXManager.  However, the XXXXXXManager can act as a container
for older components--that way we don't have to throw away the
work we already have done.

> Good thing about ECM is that component writer can easily 
> switch ThreadSafe -> Poolable and vice versa without breaking 
> any code using his component. Will this be the case for new CM?

It is a function of the Container--not the CM.  The ECM mixes the
concerns of a Container and a lookup mechanism.  It is not optimal.
Fortress is an example of a Container with a separate CM.  It is
even easier for the container or administrator to control the creation
policy for components.  It pulls that meta-info from a file.  That
way we don't run into strange things that happen in Inheritance
hierarchies that would owtherwise confuse the ECM.

> Also, I remembered about component factories (when component 
> is created on every request and destroyed on release). Will 
> this be supported with this new release()less design? You can 
> say that these single-use components are evil (as single-use 
> servlets), but this is the only choice for some legacy 
> applications/libaries.

That control is moved to your XXXXXXXManager.  It is not the
CM's responsibility to manage your component instances--it is
the container's responsibility.

> > 
> > Yes, but you wouldn't necessarily have your production (i.e. web)
> system
> > doing this either.
> We have single J2EE container here for web and back-end...

But if your expensive 8 hour routine was handled by a session bean
or something similar (JMS bound session bean?), then the Servlet
environment is not affected by the processing.

See what I am saying?  It is asynchronous to the web environment.

> > > J2EE has REQUIRES_NEW transaction management attribute 
> for the EJB 
> > > method. If you have such methods (is it considered wrong design?),
> all
> > > required for this method TxResource-s should be looked 
> up, thus you 
> > > will have more then one instance of a component.
> > 
> > J2EE also allowed you to declare Servlets as single use (not one 
> > instance per thread or sharing an instance among 
> threads)--does that 
> > make it correct design?  It was a serious bottleneck allowing a Q&D 
> > hack.
> Sometimes you have to use some legacy systems, which are not 
> necessarily written up to high-end Avalon standards... 
> SingleThreaded servlets should be considered as a way to 
> integrate such things.

You no longer have that option as of Servlet 2.3.

To unsubscribe, e-mail:
For additional commands, email:

View raw message