For me its a matter of consistency. Put simply a Service comes from a ServiceRegistry. That's consistent. This idea that some particular Service might come from here or there or this other place is not consistent. To me.
Now, I understand that there is likely a performance impact to this (Map lookup) which I assume is likely more the driver of this question. But I prefer the consistency/readability when the performance is equal/negligible. However, were the performance impact big, obviously that changes things. That's my take and my means of weighing this for ORM. On Thu, Mar 19, 2015 at 8:13 PM, Sanne Grinovero <sa...@hibernate.org> wrote: > Looks like the ServiceRegistry pattern is getting quite popular in > Hibernate Search. > > There are three default implementations (of three services) which are > provided by the hibernate-search-engine itself. > Essentially the hibernate-search-engine code looks it up, and loads > from its very same jar; I'm finding this a bit weird. > > Wouldn't it make more sense to actually look up for the service only > for alternative (non-default) implementations? > > We don't have a strategy to pick one implementation if there are > multiple implementations around (other than throwing an exception), so > having a service defined in the engine jar, essentially means noone > can plug an alternative, unless he overrides the > SearchConfiguration#getProvidedServices() method. > > So if the intention was to allow choice, something is missing. If not, > I'd rather load the default implementations explicitly (via their > traditional constructor). > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
