[hibernate-dev] Usage of the Service pattern in Hibernate Search

[Steve Ebersole]

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 <sanne at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>