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)