On 12 October 2012 14:13, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 12 Jan 2012, at 3:00 PM, Steve Ebersole wrote:
> "Java services api" == ServiceLoader I assume?
> 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.
That's one way of doing it, but you can also avoid need for
configuration properties if in different environments (Infinispan) you
only have one implementation, which is different than the usual one. I
really don't want to give a choice in that case ;)
In other cases we might have multiple choices, but might still able to
make the "right" choice without need of configuration, and maybe it's
really not worth it to give an option.
Of course there are cases in which you want to look at the
configuration properties - that's why the SPI provides the properties
- but reality is that this logic might be different depending on what
service we're talking about.
Consequentially, the ServiceManager itself doesn't deal with it but
just creates a ServiceProvider for each need: this ServiceProvider
implementation can use a selection choice as it makes most sense for
its service on a case by case.
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.
I see your point, but it doesn't really matter as we can't change this
now: it's a widely used extension point. Let's see how it evolves
during 5.0 work and then decide if it's worth changing names.
hibernate-dev mailing list