[hibernate-dev] Standalone service registry

[Steve Ebersole]

Hi Karl,

see inline...

On 01/16/2014 02:42 AM, Karl von Randow wrote:
> Hi all,
>
> I had a conversation with Steve today on IRC about refactoring the org.hibernate.service package to make it standalone. The service registry implementation is mostly separable from Hibernate core already, and it could be useful in other applications perhaps where hibernate-core isn’t a dependency. I found myself in that exact situation, which is why I’m here.
>
> I have done a test extraction of the service registry classes, excluding the BootServiceRegistry, ClassLoaderService and StrategySelector families. This was quite straight forward, worked well and worked with Hibernate core.
>
> Steve suggested that the boot service registry and associated class loading functionality would be useful standalone as well. To see what that is like, I have now done a test extraction including the BootServiceRegistry, ClassLoaderService and StrategySelector families. It has worked quite well, but was definitely major.
What do you mean it "was ... major"?  Difficult?  I would think that 
those would all peel-away pretty easily; that it would be "quite 
straight forward" as you said.

> Part of the discussion that I had with Steve this morning, and the piece that he particularly wanted to discuss here, is how to perform the extraction and where to put it:
>
> * Is this standalone service registry its own project, separate from the hibernate-orm project. Would that make it easier to use in other projects? Or is it a hibernate-ssr module within the hibernate-orm project.
>
> * Is it called hibernate-ssr or perhaps hibernate-serviceregistry? Perhaps the later is more appropriate especially if it’s a separate project.

I agree with Hardy (from IRC) that hibernate-serviceregistry is better 
than hibernate-ssr.  For me the question really comes down to choosing 
between:

a) https://github.com/hibernate/hibernate-orm/hibernate-serviceregistry
b) https://github.com/hibernate/hibernate-serviceregistry

The implications are that in the first case hibernate-serviceregistry is 
a module of the hibernate-orm project. It is still a separate jar and 
therefore still easily consumed externally.  It would be versioned along 
with the rest of the hibernate-orm modules.

The second case makes it a little more clear that it is intended for 
standalone consumption.  However, it does introduce the possibility of 
version mismatches amongst multiple consumers.  If you use Hibernate ORM 
and Hibernate Search and use the hibernate-serviceregistry yourself, all 
3 of thjese would need to agree/match on the version of 
hibernate-serviceregistry that is usable.  That exists too when 
hibernate-serviceregistry is a module of Hibernate ORM, but one variable 
is removed.

> I think the end result of the extraction I’ve done is pretty good, it does of course modify a number of classes across the hibernate-orm project (mostly just imports, though) so I’m wary that this may not be the best contribution to make as a newcomer! For reference, my WIP is here https://github.com/karlvr/hibernate-orm/compare/ssr
> I have done it inside the hibernate-orm project to best preserve the git metadata (e.g. source file renames). The project compiles, tests pass (except for some osgi stuff I don’t yet understand!), and it appears to work when used in a large Hibernate project of mine.
>
> The most interesting parts of migrating BootServiceRegistry et al over to the SSR is the Hibernate ORM dependencies in BootServiceRegistry - specifically Integrators. There were also Hibernate ORM specific features in StrategySelectorBuilder and ClassLoaderServiceImpl (specifically ClassLoaderHelper). I have created subclasses in hibernate-core of the implementations I moved to the SSR module, with the same class name as the original. These subclasses provide the Hibernate specific functionality.

Ah, I had forgotten about the direct Integrator reference on 
BootServiceRegistry.  I'd have to think through that.

What "ORM specific features" are in StrategySelectorBuilder and 
ClassLoaderServiceImpl?

> Another interesting standalone issue is the exception hierarchy. The exceptions no longer extend from HibernateException. Perhaps it would be possible to have that class in the SSR package and core to address this.
Not ideal, but not a deal-breaker either.  Not convinced that *all* 
exceptions should be runtime-variety anyway.

> I would be proud to contribute this change. I’m happy to make any changes, and I will definitely tidy up my commit messages to meet the contribution guidelines! Likewise I’m happy to throw away the work if it’s not the right approach. I had a pretty good fun morning anyway :-)
Regardless of what happens, thanks for taking a look at this!