|
||||||||
|
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 |
||||||||
Freeman Fang, thanks for the comments. Good catch on the imports – I'll add those.
Regarding #3, that's expected (I think). hibernate-osgi's HibernateBundleActivator extends HibernatePersistenceProvider and registers itself as a "javax.persistence.provider" in the BundleContext. That was necessary in order to correctly discover and utilize the container-provided JTA TransactionManager. My guess is that if you used HibernateBundleActivator as the <provider>, it would work.
In retrospect, if that's really the issue, I might try to find a way to go back to using the normal provider. I'm sure lots of users will attempt to simply reuse existing persistence units. However, this only affects container-managed setups. I guess my assumption was that a specific provider would typically be left out of the persistence unit if container-managed, but maybe that's not always the case. Any thoughts on that?
Regarding #4, we're in the middle of that. We've been working with the Karaf JPA guys to figure out how to best do the scanning. Discussion is in HHH-7993