|
||||||||
|
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 |
||||||||
@Steve concerning the BundleActivator
Blueprint and Declarative Services are just two alternative declarative ways to provide a service. They both need additional OSGi bundles. Among them a so called extender bundle is needed to scan, find an activate the declarative given service spec. I think this isn't what Hibernate wants. The dependencies are to high. I would suggest to used the programmatic way. This will work in all OSGi scenarios whether these use a form of Blueprint or other declarative service support or not.
@Gunnar concerning the OSGi JPA spec
Yes the JPA spec is a good start point, but IMHO is in the current state not satisfying. The problem with it is that the spec just copies the JEE patter that one persistance unit is one module. It means all entity classes of one EntityManager must be placed in one module aka bundle. A domain model can't be split into modules.
I would appreciate if Hibernate goes a step further and takes up again a thread starting for example here http://blog.osgi.org/2007/07/to-declare-or-not-to-declare.html
Back in that days we build modular domain models with a so called extender pattern, as you can read in the blog post.