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