2:42 a.m.
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.
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 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.
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.
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 :-)
Best regards,
Karl
6:42 a.m.
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!
9:41 a.m.
On 16 Jan 2014, at 13:42, Steve Ebersole <steve(a)hibernate.org> wrote:
> 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:
+1 for hibernate-serviceregistry. For me ssr is just too cryptic and and we usually use
full names in modules/projects.
a)
https://github.com/hibernate/hibernate-orm/hibernate-serviceregistry
b) https://github.com/hibernate/hibernate-serviceregistry
I could live with both. As Steve is saying, there are pro and cons for both. Personally, I
have a slight preference for #b.
From a consumer point of view, I am not so sure which other Hibernate
project would benefit from this atm.
Validator has no use of it. Search maybe, but I
see that a fair bit in the future. The concepts and ideas we took from ORM into
the new Search ServiceManager fulfil the requirements in Search. I don’t think there is an
immediate need there for a service registry
artifact. Not sure about OGM!?
—Hardy
10:01 a.m.
2014/1/16 Hardy Ferentschik <hardy(a)hibernate.org>
On 16 Jan 2014, at 13:42, Steve Ebersole <steve(a)hibernate.org> wrote:
>> 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:
+1 for hibernate-serviceregistry. For me ssr is just too cryptic and and
we usually use full names in modules/projects.
> a) https://github.com/hibernate/hibernate-orm/hibernate-serviceregistry
> b) https://github.com/hibernate/hibernate-serviceregistry
I could live with both. As Steve is saying, there are pro and cons for
both. Personally, I have a slight preference for #b.
I'd also prefer #b. A separate repo emphasizes that it is a separate
project (which can be used without ORM) and it e.g. would allow to set up
separate permissions, so there could be people which can commit to the
registry and not to ORM and the other way around.
>From a consumer point of view, I am not so sure which other Hibernate
project would benefit from this atm.
Validator has no use of it. Search maybe, but I see that a fair bit in the
future. The concepts and ideas we took from ORM into
the new Search ServiceManager fulfil the requirements in Search. I don’t
think there is an immediate need there for a service registry
artifact. Not sure about OGM!?
We use the registry (as it is, i.e. no modifications or copied stuff) quite
a bit, but I don't think we'd gain much atm. if it was a separate artifact.
We'd have to use the version pulled in by ORM all time anyways.
—Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:48 p.m.
On 17/01/2014, at 1:42 am, Steve Ebersole <steve(a)hibernate.org> wrote:
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.
The first part, without Boot + Class + StrategySelector is easy. The only interesting
dependencies are HibernateException, CoreMessageLogging and JmxService. I resolved all of
those pretty easily, and migrated JmxService into the org.hibernate.service.spi package,
next to its marker class Manageable.
I moved two log methods from CoreMessageLogging to the new ServiceRegistryMessageLogging.
The generated source is working nicely in Gradle, I presume there will be an i18n
implication for this.
The majorness (or is it major-ity) of the second part is related to the question below -
there were quite a few places where there was ORM specific functionality woven in. So from
that point of view, the standaloning may also be considered beautiful from a code
structure pov.
…
> 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?
I managed to separate Integrator pretty nicely I think. Hibernate core has its own
BootServiceRegistry implementation that supports Integrators by subclassing the new
AbstractBootServiceRegistry in SSR. I added the necessary hooks - one or two.
StrategySelectorBuilder loads dialects, JTA platforms, transaction factories and
multi-table bulk id strategies as part of its code. Again, this was easily separated out.
I created an AbstractStrategySelectorBuilder in SSR and a subclass
StrategySelectorBuilder, in its original place in core, that overrides a new
addBaseline(StrategySelectorImpl) protected method and calls the addDialects etc methods
extracted from the original. Pretty clean.
The StrategyRegistrationProvider was a bit interesting. This is referenced by its full
class name as property files in the individual modules to load strategy registration
providers. As you’ll note from the commit log I only discovered this later in the
migration. So I’ve added the capability to AbstractStrategySelectorBuilder to specify the
StrategyRegistrationProvider sub-interface to use, modifying the original
StrategyRegistrationProvider in core to extend the new one in SSR. This works pretty well.
I’ve then created a DefaultStrategySelectorBuilder to live in SSR which uses the
StrategyRegistrationProvider base-interface and doesn’t have any baseline strategies.
ClassLoaderServiceImpl has a dependency on ClassLoaderHelper, which allows overriding of
the context class loader. From the comments, this is a temporary solution, but I obviously
wanted to maintain it. There was also a deprecated method fromConfigSettings(Map
configValues) which is called from PersistenceXmlParser in JPA that I didn’t want to bring
to SSR as it contains core specific reference (AvailableSettings.HIBERNATE_CLASSLOADER
etc). I modified the original ClassLoaderServiceImpl to be a subclass of the impl in SSR
and to contain those specific pieces of functionality. I also modified the
BootstrapServiceRegistryBuilder so that it could choose the default ClassLoaderService
implementation, and core’s builder chooses core’s one.
I did all of the changes in little steps in the commit logs, so when it comes to the point
of following the process it should be pretty easy to see the thinking in each step!
> 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 only had to modify two tests, IIRC, that relied on those exceptions being
HibernateException subclasses. It doesn’t seem likely that much user code relies on those
exceptions as they feel much more internal to ORM. *fingers-crossed-emoji*
4306
days inactive
4306
days old
4 comments
4 participants
participants (4)
-
Gunnar Morling -
Hardy Ferentschik -
Karl von Randow -
Steve Ebersole