[hibernate-dev] Usage of the Service pattern in Hibernate Search
steve at hibernate.org
Sat Mar 21 11:55:58 EDT 2015
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
That's my take and my means of weighing this for ORM.
On Thu, Mar 19, 2015 at 8:13 PM, Sanne Grinovero <sanne at hibernate.org>
> 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 at lists.jboss.org
More information about the hibernate-dev