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 21:19:22 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > 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.
> 
> 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 );
> }

Shouldn't some standard (default, etc) Manager will be available?

I really not exactly understand necessity of different managers, or,
let's put it this way, absence of some standard/default manager
interface. I got the part that lookup and component lifecycle will be
implemented by two different entities, not the one component manager (as
of now) - and I have no issues with this.

But I don't get why you force different manager for every different
component. Then, you won't be free anymore to switch between different
component implementations (or change implementation) - you will break
XXXXXManager interface which depends on implementation of the component.

To illustrate the point: manager of ThreadSafe component won't have
release(), manager of non-disposable component also won't have
release(). If you ever decide that your component must be disposable or
it must be poolable you have to change XXXXXManager interface, and, as a
result, rewrite *all* the clients of this interface.


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

What about cast to XXXXXManager?

  MyManager mm = (MyManager)cm.lookup("role");

While removing one cast another was added.


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

Same here.

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