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! _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
