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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
