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.
The ServiceProvider<T> can contain logic to make a choice about
Service implementation you're supposed to get, as it receives the
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
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
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
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
Right. I think we need to sort this out. Right now the code seems to be a mixing different