cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 20:13:07 GMT


> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> > 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.

Berin,

OK how about this: You get all managers you need in compose().
Then when you need a component you call the manager you obtained in
compose(). If this is what you mean, then I'm fine with it. Some extra
code, but it's just like EJB:s XXXXXHome interface.

Second, how do you handle switching between pooled and threadsafe 
implementations of a component interface? The way I see it, you have
to assume that the component is pooled and thus it must have some
way of being released. So does this mean that we will have a
standardized
XXXXXManager interface with a getInstance() and a release() method?
Or will the XXXXManager be specific to each component interface?
Can you give samples of three different XXXXManager interfaces, just 
so I can see what differences there may be?

Third, am I the only one getting three copies of every email on 
avalon-dev and cocoon-dev?

/LS


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


Mime
View raw message