> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
