[
https://issues.apache.org/jira/browse/OPENJPA-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736850#comment-16736850
]
Romain Manni-Bucau commented on OPENJPA-2766:
---------------------------------------------
Well there are two things here - so likely multiple tickets:
1. enhancing the scanning to support the whole classpath in a pluggable fashion
with xbean is doable but can't be the default since the server must do it in
general (it already has the info and it must just reuse it instead of
multiplying the scanners, this is what does tomee and jpa based apps). It also
requires include/exclude/overlap-handling config in the unit (not an issue but
just pointing it out) cause often in 3rd party some jpa entities hang and are
not desired.
2. making it OSGi friendly is not about making the factory dynamic directly
(openjpa being the impl) but making it a whiteboard. TomEE has something close
with the reloadableentitymanagerfactory -
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/ReloadableEntityManagerFactory.java
- which can be imported (once cleaned) but I suspect for OSGi case you want to
do it in aries jpa (http://aries.apache.org/modules/jpaproject.html) cause it
is at the end quite specific to OSGi and its bundle lifecycle management
In other words I'm all fine to enhance 1 but I think, due to current asf state,
2 belongs outside openjpa which would stay the core and spec impl and not the
full OSGi integration.
Hope it makes more sense phrased this way
> Modularity support
> ------------------
>
> Key: OPENJPA-2766
> URL: https://issues.apache.org/jira/browse/OPENJPA-2766
> Project: OpenJPA
> Issue Type: New Feature
> Reporter: Matt Pavlovich
> Priority: Major
>
> Support modular organization of entities so that all entities do not need to
> be contained in the same jar, or referenced in a single persistence.xml
> <class> listing.
> Use cases:
> 1. Jar A contains entityA, Jar B contains entityB. (EntityB may or may not
> extend from entityA.)
> 2. Jar X contains persistence.xml defining the PU
> 3. Jar C contains entityC and a list of classes that extend entityA. Jar X
> persistence unit should be able to persist entityC and its collection of
> entityA, entityB.. etc
> Features:
> 1. Auto-classpath scanning (perhaps for persistence-fragment.xml.. then
> enumerate)
> 2. Support manual registration and unregistration of entity classes (not just
> class names) to support OSGi environments that have per-bundle classloaders
> and deploy/undeploy support.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
