|
||||||||
|
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 I have to be honest that this sounds like a short coming in OSGi. I don't think it is uncommon at all that a group/organization/company puts out a product/project as a series of jars. In Hibernate we do this specifically to isolate dependencies. Furthermore, I don't think it is uncommon that these jars share code. Forcing these use cases to use more and more smaller jars is hacky imho.
Helmut Pasch IMHO any solution calling for multiple persistence.xml files is horrible. Personally I think classpath scanning is the best option for this, which yes can still work in OSGi; in OSGi, its just a question of which ClassLoader(s) to scan (interestingly not all that much different from JEE in that regard). If "multiple persistence.xml files" is the path Enterprise OSGi wants to take (essentially violating the JPA spec), then IMHO OSGi should make the OSGi environments responsible for aggregating together the archives discovered via persistence.xml look ups and handling that to the JPA provider.