Re: [hibernate-dev] Concept of "service availability"
On 08/28/2012 02:39 PM, Steve Ebersole wrote:
The problem there is timing. Hibernate already has to be started in
order
for "this" to work. But what "this" is doing is providing things
Hibernate
needs to start. Its chicken-egg.
Interestingly this is very similar to the proposal Scott Marlow and I made
to the JPA group. And in fact that could be leveraged here. Essentially
that proposal was to make JPA bootstrapping a 2-phase process rather than
just a single "build it" phase. Here however that would mean (iiuc, and
please correct me if I do not) Hibernate needing 2 OSGi services. One that
builds the BootstrapServiceRegistry and MetadataSources/Configuration and
then another that builds the SessionFactory/EntityManagerFactory. The type
of things you discuss here would depends on the first service but somehow
need to be ordered before the second Hibernate service.
I have seen (and developed) many services which use a kind of iterative
process. If they discover a service A which is interesting for them and
realize they need another service B which is not yet available, they put
the service A on hold (whatever on hold means), until a bundle, which
announce service B is available (or they wait forever if no bundle ever
announces a service B) and then continue with the handling of service A.
This could be implemented with the help of
ServiceTracker,ServiceListener and/or BundleListener (and other standard
osgi classes and interfaces)
I normally implement it in the following way:
The BundleActivator implements the ServiceListener and or BundleListener
and reacts on Service-Events(modified properties, service registered,
service unregistered) or Bundle-Events (bundle installed, uninstalled,
resolved, unresolved, starting, stopping, etc.). This could be used to
initiate a scan of the bundle for resources, register/unregister
interesting services, etc.
So hibernate in the osgi framework could do a multi step bootstrap like:
- On Bundle start (when the BundleActivator gets called), register
Bundle- , ServiceListeners and ServiceTrackers to get hold on
modifications which occur from now on (and track the services and/or
bundles of interest if events got passed to the listeners).
- Next step would be to look if there are already interesting services
(and bundles) which got activated before the hibernate bundle got
activated (and add them to the list of tracked bundles and/or service if
they are not already tracked ).
From now on, you could then react on life-cycle changes for bundles and
services and modify the internal registries accordingly ( or do some
other meaningful things with the information)
this means you have two phases:
- Initialisation and discovery of bundles and service which are already
present.
- Dynamic life cycle which react on bundle and service changes.
Of course assuming we even want to go that route in Hibernate source.
The
other option is the OSGi container adding that bundle to the ClassLoader it
passes Hibernate so Hibernate can do the auto-discovery. Maybe I am
missing some options?
Please correct me, but if you have a Bundle (or ServiceReference which
could be used to get the implementing Bundle) you can use the bundle to
load classes and resources which are contained in the bundle (yes I know
there are also Permissions in OSGI, but you can grant the hibernate
bundle(s) the appropriate permissions to be allowed to load classes in
that way - but the permission system is another issue which shouldn't
cause problems here)