|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
Martin Neimeier Thanks for that break down. Couple of thoughts...
1) As far as the concept of "OSGi services" and "OSGi service registry", I would like to investigate how that can be hooked into the Hibernate org.hibernate.service.Service/org.hibernate.service.ServiceRegistry infrastructure. org.hibernate.service.ServiceRegistry was designed to be extensible for cases just like this. However, what I clearly do not want is force feeding OSGi dependencies on applications not using OSGi.
2) As far as "extend[ing] his classloading with a way to incorporate osgi service lookup", we have, I believe, all the necessary hooks already. We have a ClassLoaderService as I already mentioned. It may seem like a chicken-egg problem to have a service help in the loading of services, unitl you consider that Hibernate service registries are hierarchical. ClassLoaderService is part of what is called the "bootstrap service registry". Additionally ClassLoaderService has a hook already to account for discovery via java.util.ServiceLoader, though not in the standard way java.util.ServiceLoader normally works. It does significant management of the ClassLoader that java.util.ServiceLoader is allowed to use. For the details, have a look at org.hibernate.service.classloading.internal.ClassLoaderServiceImpl#loadJavaServices which specifically leverages the ClassLoader built in org.hibernate.service.classloading.internal.ClassLoaderServiceImpl#buildServiceLoaderClassLoader. Yet another option would be a "service registry service", aka, a service that acts as a registry for service instances. Using ConnectionProvider as a reference, we would have a ConnectionProviderRegistryService which would hold named references to available ConnectionProvider implementations.
3) As far as some of these "internal uses" by other jars, this is something we need to figure out in my humble opinion. The other purpose served by putting things into the internal package is to designate that it is not intended for consumption by code outside the set of Hibernate jars. Util stuff being the most common case here. We need these classes usable across all the jars. And no, hibernate-utils is not the answer
4) Yes, we have not visited the package split on hibernate-envers yet, nor have we done it on certain hibernate-core packages yet (you and I discussed org.hibernate.loader specifically for example already). That should get done as part of this effort.