> 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.
>
I have some reservations regarding the release() method
or equivalent below, but it seems like we're on the same
wavelength.
> > 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.
By "necessary" do you mean this:
Either the Manager, or the component itself,
will typically provide some method, after which it has
been called,
the component is invalidated and maybe returned to a pool.
This method *must* be called by the client.
So, DataSourceComponent will not have a release()
as you would call close() on the connection instead.
The two examples with XMLSource and sink do not have
release(), as the endDocument event signals the end-of-
duty-cycle for the component.
But if there wasn't any such methods (that is, the
component itself does not provide a method for the
client to say "I'm done with you"), the Manager
must provide a release(XXXX component) method or
equivalent.
Is this correct?
Furthermore, the associated XXXXManager interface is not
implementation specific. You can switch from pooled to
threadsafe and back without changing the way you use it.
Is this correct?
> 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.
Exactly, and that is why it must die. The idea was good -
you get selection of components orthogonal from the components
themselves. But the problem you specify pretty much makes them
useless.
But - where do you put the lookup(String role, Object hint)
method (or equivalent)? In the CM interface? It would appear
that you'd put it in the XXXXXManager interface.
Does this mean that you will merge selectors with Managers?
Or will a ComponentSelector be an XXXXXManagerSelector?
Finally, I would like this name change for A5:
ComponentManager -> ComponentDirectory
XXXXXManager -> ComponentManager
I think it would reduce confusion. But that's for later....
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
