Hi Rex,
I too would like to know which parts of the spec cover this.
for (1), karaf already has a wrap deployer based (I think) on a pax project.
It uses bnd under the covers and results in (I think) dynamic imports for all
the packages used by the wrapped jar. We also need to be careful not to wrap
something that is already a bundle. It may also be spec compliant to ask the
server administrator to convert the jpa provider jar(s) into bundles. I really
doubt the lib directory is mentioned in the spec.... if it is the entire spec
committee was asleep...
for (2), I think we should wait a few days. In my private work on architecture
I've eliminated the dependencies in Environment. With the possible exception
of base classes related to enhancement, I don't think the application actually
needs access to the jpa provider classes. Does anyone know or can anyone
figure out what provider imports are needed to make openjpa work? Aries might
have solved this problem....
thanks
david jencks
On Apr 5, 2011, at 2:16 AM, Rex Wang wrote:
> HI Devs,
>
> These days I am looking into this new feature that we need implement to
> comply the Java EE 6 Spec.
>
> This feature requires the ability to "plug-in" a vendor JPA Provider to the
> Java EE server, and the JPA app can "pick-up" the vendor provider and get
>
> the corresponding EntityManagerFactory. That is, let's take a use case for
> example, the steps are:
> a. User put a Oracle topLink.jar into the server's lib folder.
> b. In the JPA app's persistence.xml, specify the provider as following:
>
> <provider>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider</provider>
> Then the entity manager factory should be created from the toplink's
> EntityManagerFactoryProvider by our server.
>
>
> Currently, we don't have such ability because of the following obstacles:
> 1. We are running server on OSGi framework. There is not way to just put-in a
> jar file and make it work for other Bundles' classloader.
> 2. We are tight coupling the JPA20 builder to Openjpa. In the
> PersistenceUnitBuilder, we set the defaultEnvironment with:
> <dependencies>
> <dependency>
> <groupId>org.apache.geronimo.configs</groupId>
> <artifactId>openjpa2</artifactId>
> <version>${version}</version>
> <type>car</type>
> </dependency>
> </dependencies>
> This will add all the export-packages from openjpa to the JPA app bundle
> when deploy, but it is actually useless for the ones specified other vendor
> providers.
>
>
> For #1, I think we should add the ability to convert a normal jar to OSGi
> bundle. I looked into the maven-bundle-plugin, and the aQute bndlib should be
> a good tool to do this. We can just provide the basic function that wrap a
> jar and:
> Export-Package: *
> Import-Package: <packages inside the target jar>
> to make it as bundle. And in the long term, we can provide a portlet in admin
> console for user to customizing his bundle.
>
> For #2, User need input the dependency in the jpa app's deployment plan and
> specify to the bundle generated by geronimo in #1, such as:
> <dependencies>
> <dependency>
> <groupId>geronimo.generated.bundles</groupId>
> <artifactId>topLink</artifactId>
> <version>1.0</version>
> <type>jar</type>
> </dependency>
> </dependencies>
> Then all the topLink export-packages will be imported by the jpa app bundle
> of user. We won't need merge the defaultEnviroment(i.e. openjpa) in the
> PersistenceUnitBuilder if use specify a vendor provider in persistence.xml.
> Another approach is we can add the imports
> "oracle.toplink.essentials.ejb.cmp3;" when analyzing the persistence.xml in
> PersistenceUnitBuilder so that user won't need manually add a deployment plan
> and input the dependency.
>
>
> Any comments?
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
