|
||||||||
|
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 |
||||||||
Again, I think I already covered all this, but for clarity I guess...
1) Classloading in Hibernate. Again, all ClassLoader interactions in Hibernate now go through a dedicated service : org.hibernate.boot.registry.classloading.spi.ClassLoaderService. So as long as this ClassLoaderService is set up and configured correctly everything will work even in an osgi environment. That is not the concern. The concern is that in an osgi environment something has to set this ClassLoaderService up properly, where something is the application or the osgi environment. Which leads to...
2) OSGI Manifests. Sure we could just create a manifest that names Hibernate's incoming and outgoing dependencies and be done with it. But again, we still have this concern about setting up the ClassLoaderService properly and other nice-to-haves (like auto registering Types or Services or Integrators etc from the user bundles) and to have this occur via an activator. That is the discussion that was going on.