Re: [hibernate-dev] ServiceRegistries and OSGi
Alright, 3 week late response ;)
In hibernate-osgi, SF/EMF initialization simply uses the #with methods on
BootstrapServiceRegistryBuilder, then builds a StandardServiceRegistry through the
StandardServiceRegistryBuilder. Originally, I was implementing a custom ServiceRegistry
that hooked directly into the OSGi registry. However, the consulting with Tim Ward
changed that. To prevent versioning conflicts, etc. hibernate-osgi only registers its own
set of services and the services within the client persistence bundle (discovered when an
SF/EMF is requested). Because of that, I simply stuck with with the
BootstrapServiceRegistryBuilder and StandardServiceRegistryBuilder.
It seems that the ServiceRegistry is a bit of an all-or-nothing concept. For instance, it
would be useful to provide a custom ServiceRegistry, but still kick off the
StandardServiceInitiators. Maybe that means tying StandardServiceInitiators into
something more like an AbstractServiceRegistry, rather than solely within
StandardServiceRegistryBuilder? Otherwise, *all* standard services would need to be in
the OSGi registry for hibernate-osgi to discover them. That's fairly straightforward,
but could cause problems if an OSGi environment had more than one version/instance of
Hibernate running (it happens).
The one other improvement that I can think of is an easier way to provide a custom
ServiceRegistry in JPA (Bootstrap -> EntityManagerFactoryBuilder). Unless I missed
something, I think it assumes the standard registry is always used.
Brett Meyer
Red Hat Software Engineer, Hibernate
----- Original Message -----
From: "Steve Ebersole" <steve(a)hibernate.org>
To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org>
Sent: Wednesday, May 22, 2013 3:51:39 PM
Subject: [hibernate-dev] ServiceRegistries and OSGi
Now that OSGi support is in place and we know it is being used, I am
curious whether the concept of ServiceRegistry helped or hindered in
that process?
One of the major reasons to define such a ServiceRegistry was the idea
that it would help porting Hibernate into other containers and other
runtimes, not just traditonal JSE/JEE environments. Specifically OSGi
was one of the things considered, although in a very generic sense back
then. So part of the reason I ask is that I wonder how successful we
were in that, first; and then, in areas we can get better, how?
Now is a great time to review that as we get ready to start making a
push towards 5.0 after 4.3 (JPA 2.1 support) gets stabilized...
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev