3:13 p.m.
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
3:31 p.m.
New subject: [HSearch] ServiceManager and services
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?
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.
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.
Sanne
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:29 p.m.
New subject: [HSearch] ServiceManager and services
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
6:19 p.m.
New subject: [HSearch] ServiceManager and services
On 12 Jan 2012, at 5:29 PM, Emmanuel Bernard wrote:
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.
I orientate myself in this case at the ServiceLoader docs (especially since we are using
this mechanism as well) which says:
"A service is a well-known set of interfaces and (usually abstract) classes. A
service provider is a specific implementation of a service."
What I am saying is that by calling it a ServiceManager and by using the ServiceLoader API
I have a certain expectation on how things
will work. I would have expected that each of the services has its own service file and
that we determine the service to use by using the
Service Loader API + some config code.
I don't see how renaming this class a BeanLifeCycleManager makes
any of
this better.
Just trying to avoid wrong expectations.
--Hardy
11:45 p.m.
New subject: [HSearch] ServiceManager and services
On Mon 2012-10-15 18:19, Hardy Ferentschik wrote:
> Basically for you a Service must allow for multiple
implementations
> and a ServiceManager must offer a way to switch between various
> implementations.
I orientate myself in this case at the ServiceLoader docs (especially since we are using
this mechanism as well) which says:
"A service is a well-known set of interfaces and (usually abstract) classes. A
service provider is a specific implementation of a service."
What I am saying is that by calling it a ServiceManager and by using the ServiceLoader
API I have a certain expectation on how things
will work. I would have expected that each of the services has its own service file and
that we determine the service to use by using the
Service Loader API + some config code.
I don't think we use the ServiceLoader API nor implementation. though we
do reuse the pattern of finding services by a the META-INF service.
What is a bit unfortunate is that what the JDK ServiceLoader calls a
service, we call it a ServiceProvider and what they call a service
provider we call it a given implementation of ServiceProvider offering
the lifecycle management of a specific service.
In other words, the service we offer is the service provider lifecycle.
We hopped one level.
4210
days inactive
4213
days old
4 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero