Re: [hibernate-dev] Concept of "service availability"

Not sure this will actually help with OSGi in terms of auto-discovery at all after thinking about it some more. The problem is that in order for auto-discovery to happen, Hibernate would need to have visibility into the jar defining the service anyway in order to auto-discovery it. On the bright side, I realized another benefit. It would finally be possible to report the available types of a particular service/strategy. For example, show me all the available ConnectionProviders; all the available Dialects; etc... On Fri 24 Aug 2012 08:51:09 PM CDT, Steve Ebersole wrote: > Would be nice to consolidate the notions of > "ServiceAvailabililtyNotifier" and "ServiceContributor" (that I just > added on metamodel). Such that a ServiceContributor would be able to > regsiter the short names as well. > > > On Thu 23 Aug 2012 03:58:10 PM CDT, Steve Ebersole wrote: >> Ok, going to start working this up on master tomorrow. We will just >> tackle the "going away" problem if/when it actually arises. >> >> On Tue 21 Aug 2012 05:55:31 PM CDT, Steve Ebersole wrote: >>> Everyone else ok with this idea? >>> >>> On Tue 21 Aug 2012 08:27:25 AM CDT, Steve Ebersole wrote: >>>> Not so concerned about shutdown situations. >>>> >>>> More, imagine a custom ConnectionProvider implementation provided by >>>> user. And the use case of upgrading that implementation "in flight". >>>> I think thats the OSGi use case. And not so sure Hibernate should be >>>> implementing this self healing. I guess it depends how deeply we want >>>> to support the OSGi model above and beyond JSE/JEE >>>> >>>> Obviously a used ConnectionProvider just going away is going to render >>>> the SessionFactory using it broken. >>>> >>>> On Tue 21 Aug 2012 08:22:11 AM CDT, Scott Marlow wrote: >>>>> On 08/20/2012 11:19 PM, Steve Ebersole wrote: >>>>>> This ties together a few different discussions that have been >>>>>> going on >>>>>> simultaneously on the mailing list that I think are all related. >>>>>> >>>>>> Right now to configure certain services (select one impl over >>>>>> another) >>>>>> users generally give the FQN for that impl Class. For example to >>>>>> use >>>>>> C3P0 connection pooling users would say: >>>>>> >>>>>> hibernate.connection.provider_class = >>>>>> org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider >>>>>> >>>>>> >>>>>> >>>>>> We have discussed why this is bad even before any of the OSGi >>>>>> discussions and the solution we wanted to shoot for was that of >>>>>> naming >>>>>> "selectors" such that the user would instead say: >>>>>> >>>>>> hibernate.connection.provider_class = c3p0 >>>>>> >>>>>> And "c3p0" here would be interpreted to mean "instantiate and >>>>>> configure >>>>>> the >>>>>> org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider >>>>>> >>>>>> >>>>>> Class". But that still means a limited set of short name values >>>>>> *and* >>>>>> still gives us a problem (iiuc) under OSGi due to visibility. >>>>>> >>>>>> So what I propose instead is a way for service implementors to be >>>>>> registered under a short name via discovery. The main piece to >>>>>> this is >>>>>> the "registry" (which is also a service under the >>>>>> BootstrapServiceRegistry): >>>>>> >>>>>> interface AvailableServiceRegistry extends Service { >>>>>> public<T> Class<? extends T> >>>>>> findAvailableServiceImplementor(Class<T> serviceRole, String >>>>>> selector); >>>>>> } >>>>>> >>>>>> class AvailableServiceRegistryImpl >>>>>> implements AvailableServiceRegistry, >>>>>> ServiceRegistryAwareService { >>>>>> private Map<Class,Map<String,Class>> availableImplementors = >>>>>> ...; >>>>>> >>>>>> @Override >>>>>> public<T> Class<? extends T> >>>>>> findAvailableServiceImplementor(Class<T> serviceRole, String >>>>>> selector) { >>>>>> // purposely simplistic :) >>>>>> return availableImplementors.get( serviceRole ).get( >>>>>> selector ); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public void injectServices(ServiceRegistryImplementor >>>>>> serviceRegistry) { >>>>>> final LinkedHashSet<ServiceAvailabililtyNotifier> >>>>>> notifiers = >>>>>> serviceRegistry.getService( ClassLoaderService.class >>>>>> ).loadJavaServices( >>>>>> ServiceAvailabililtyNotifier.class ); >>>>>> for ( ServiceAvailabililtyNotifier notifier : notifiers >>>>>> ) { >>>>>> for ( ServiceAvailabililty availability : >>>>>> notifier.getAvailabilities() ) { >>>>>> // again, purposely simplistic >>>>>> Map<String,Class> serviceImplementors = >>>>>> availableImplementors.get( availability.getRole() ); >>>>>> serviceImplementors.put( >>>>>> availability.getSelector(), >>>>>> availability.getImplementor() >>>>>> ); >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Outstanding question... Especially in OSGi, where service bundles >>>>>> can be >>>>>> added/removed, how do we best account for cleaning up no-longer >>>>>> valid >>>>>> references (even more importantly perhaps, what the hell does it >>>>>> mean to >>>>>> Hibernate when a ConnectionProvider implementation, for example, >>>>>> that is >>>>>> in use gets taken away?!?). Perhaps this is just where an >>>>>> OSGi-specific >>>>>> Hibernate ServiceRegistry implementation would come into play. >>>>>> >>>>> Adding Jesper as we were talking about how to handle "quiescence >>>>> shutdown" at the AS level, which sounds related. Once we take the >>>>> ConnectionProvider away, I would expect the Hibernate >>>>> session(s)/session factory to be broken. If/when the >>>>> ConnectionProvider comes back, Hibernate would need to re-establish >>>>> it. I'm thinking that we need a neutral (autonomic) API/SPI for >>>>> attempting to re-establish the ConnectionProvider. >>>>> >>>>> For the most part, a "quiescence shutdown" of the AS, would mean >>>>> keeping the ConnetionProvider alive until the end (of the planned >>>>> shutdown). I'm thinking that being able to re-establish the >>>>> ConnectionProvider would still be useful (for AS "quiescence >>>>> shutdown"), especially if something goes wrong during the shutdown >>>>> and >>>>> manual intervention is needed. >>>>> >>>>> To me, the process of re-establishing the ConnectionProvider, >>>>> could be >>>>> labeled "self healing" (with the help of an autonomic API/SPI). >>>>> >>>> -- >>>> steve(a)hibernate.org >>>> http://hibernate.org >>> -- >>> steve(a)hibernate.org >>> http://hibernate.org >> -- >> steve(a)hibernate.org >> http://hibernate.org > -- > steve(a)hibernate.org > http://hibernate.org -- steve(a)hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev