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