[hibernate-dev] Concept of "service availability"

[mailing at bibbernet.org]

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)