cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 16:46:59 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org]
 
<snip/>


> > > 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.

NOW I SEE THE LIGHT! :)

I did not get this from your initial post.


<snip reason="agreed"/>


> > > 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.

I'm instantiating Avalon from enterprise application (ear), not from web
application (war) :)

<snip/>

> > 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.

I won't miss it. But the point is - there is migration path.

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message