[hibernate-dev] [HSearch] ServiceManager and services

[Sanne Grinovero]

On 12 October 2012 14:29, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> On 12 Jan 2012, at 2:58 PM, Sanne Grinovero wrote:
>
>> I was having similar doubts when recently converted the Serializer
>> service to a Service.
>
> good :-)
>
>> The ServiceProvider<T> can contain logic to make a choice about which
>> Service implementation you're supposed to get, as it receives the
>> configuration properties.
>
> Again. In this case we have a LifeCycleManager and not a ServiceManager. The choice of
> implementation (service) is still done in the ServiceProvider impl which seems somehow
> upside down.
>
>> In short how different alternatives are discovered, that's not
>> something the ServiceProvider specifies, you have a lot of freedom in
>> that sense: the Provider can define whatever logic it wants; you're
>> supposed to have a single provider, but this one can be overriden by
>> other modules.
>
> how?

As said below, you have an example in JGroupsChannelProvider.
Depending of Muxing Channels are available, and if a JChannel instance
was injected, and depending on other configuration properties it's
going to produce a different implementation of a MessageSender.
That's good as the client code doesn't have to deal with it, it just
needs a MessageSender, whatever that means in the runtime we are
running in.

FYI a Muxing JChannel is something you can have on AS7 so to avoid
needing to start our own JGroups channels and get a dedicated channel
on an existing connection. Our backend of course doesn't care, it just
wants some way to send messages.

>
>> Example: JGroupsChannelProvider has a start() method in which it
>> decides what exactly it's going to create.
>
> not sure I fully understand this concept
>
>
>> I agree it could do better, for example by listing alternative
>> implementations for the Provider to choose from, but until we don't
>> need that there's no reason to over engineer it.
>
> I am all up for not over engineering, but what we are engineering should do what
> it implied to be doing. That's not the case here imo.
>
>> It's likely that this will evolve; especially the Avro picking stuff
>> you mention.. doesn't look like we finished that; in fact there is a
>> TODO in SerializationProviderService. I'll check JIRA to see if we're
>> tracking that.
>
> Right. I think we need to sort this out. Right now the code seems to be a mixing different concepts.

That's specific for Avro anyway, and as Emmanuel said not really
important as there is no visible benefit (other than removing a
question mark). I don't think it's a good idea to change the meaning
of this wiring fabric now: I'm not against it in the future, just that
we're late now and in need of a stable release.

Cheers,
Sanne

>
> --Hardy