On Fri 2012-10-12 15:13, Hardy Ferentschik wrote:
On 12 Jan 2012, at 3:00 PM, Steve Ebersole wrote:
> "Java services api" == ServiceLoader I assume?
correct
> Going on that assumption:
>
> No. ServiceLoader is just a discovery mechanism. There still needs to be something
that, as you say, negotiates amongst the various discovered implementations of a
particular service. 2 well known ServiceLoader uses are JDBC drivers and image
processors, each illustrating a different approach that are really inherent to their
respective problem domains. In the case of JDBC drivers, the discovery is just used to
register all the available drivers; users must still specify which driver they want via
JDBC url protocol. In the case of image processing (as I understand it anyway, not really
my forte) the choice of processor is more intrinsic to the image you ask to have processed
based on MIME type.
>
> Here is sound like you more have the JDBC style, where discovery is just making the
complete set of possibilities known. The user would still need to make a distinction. Or
maybe you have some special rules like (a) using the standard service if it is the only
one discovered; (b) using the "other" service if 2 are discovered; (c) requiring
the user tell you if 3 or more are found. Many ways to skin that cat.
Right. I would expect the user to make this distinction via the configuration.
I think really the problem is that what we have is actually not a ServiceManager (at
least not what I understand under this term). It is a fancy way to instantiating a class
and giving it a life cycle (aka #start(), #stop()).
We really have more of a BeanLifeCycleManager.
Basically for you a Service must allow for multiple implementations
and a ServiceManager must offer a way to switch between various
implementations.
To me a Service renders a... service. In Hibernate Search services are
lazy loaded and we have the notion of ServiceProvider to cope with that.
We also happen to have a way to chose between one implementation vs
another via configuration (see backends, optimization strategies etc).
I don't see how renaming this class a BeanLifeCycleManager makes any of
this better. AFAIK the only beans that have lifecycles are managed bean,
CDI beans or Enterprise JavaBeans. None of them mandate an interface /
implementation split and they don't carry the idea of pluggable
implementations necessarily.
Emmanuel