On 12 October 2012 14:29, Hardy Ferentschik <ha...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
