> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
> > 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.
That's exactly what I mean.
> 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?
By removing the release() method from the CM, we place the
responsibility on the XXXXManager. That means that the
XXXXManager has the release() method--if it is necessary.
The XXXXManager would be specific to the type of component or
processing artifact that it manages. This allows for more
intelligent resource management and integration with other
components.
As to your request for the XXXXXManager interfaces, here you
go:
interface DataSourceComponent
{
Connection getConnection(); // current interface
Connection getConnection(String name); // for next version
}
interface GeneratorManager
{
XMLSource getSource( String type, Map objectModel, String source,
Parameters params );
}
interface SerializerManager
{
ContentHandler getSink( String type, Map objectModel, Parameters
param,
OutputStream out );
}
The DataSourceComponent does need to be extended because it is
threadsafe, and there are potentially several different databases
one system may need to interact with. Usually there is a default,
which is why the original getConnection() would remain. But it would
be wasteful to have to go to a Selector in *some* environments, but
get the DataSourceComponent directly in *other* environments.
You see, the existence of the ComponentSelector does change the way
we write our components. Either our components will break if the
does not exist, or the logic to handle either situation will add
unnecessary bulk.
The GeneratorManager and the SerializerManager are slightly different
in that we don't have a "source" parameter but have an "out" parameter
instead.
Another benefit of this approach is that we don't have to do casting,
and risk ClassCastExceptions at runtime.
>
> Third, am I the only one getting three copies of every email on
> avalon-dev and cocoon-dev?
No, It happens when we hit reply-all, and the mail client adds the
original sender along with the two mail lists. I am getting them
two.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
