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