geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Re: [Discussion] JPA Pluggability
Date Wed, 06 Apr 2011 02:19:21 GMT
ejb-3_0-fr-spec-persistence.xml  -> ejb-3_0-fr-spec-persistence.pdf

2011/4/6 Rex Wang <>

> 2011/4/6 David Jencks <>
>> Hi Rex,
>> I too would like to know which parts of the spec cover this.
> Hi,
> The use case should be extracted from the ejb-3_0-fr-spec-persistence.xml,
> it seems not be well tested in Java EE 5 TCK. The descriptions are:
> ~~~~~~~~~~~~~~~
> Chapter 7 Container and Provider Contracts for Deployment and Bootstrapping
> 7.1 Java EE Deployment
> 7.1.1 Responsibilities of the Container
> ....
> Once the container has read the persistence metadata, it determines the
> javax.persistence.
> spi.PersistenceProvider implementation class for each deployed named
> persistence
> unit. It creates an instance of this implementation class and invokes the
> createContainerEntityManagerFactory
> method on that instance. The metadata—in the form of a Persistence-
> UnitInfo class—is passed to the persistence provider as part of this call.
> The factory obtained as a
> result will be used by the container to create container-managed entity
> managers. Only one EntityManagerFactory
> is permitted to be created for each deployed persistence unit
> configuration. Any number of
> EntityManager instances may be created from a given factory.
> ......
> ~~~~~~~~~~~~~~~~
> JBoss is also dealing with this, ref
>> 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...
> Yes, no "lib" mentioned. The use case is just one example.. The actual
> problem is we must provide the ability to convert a jar to osgi bundle so
> that the vendor provider jar can be used in our server. Further more, the
> jdbc driver jars also meet the same situation.
>> 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....
> IIUC, should be org.apache.openjpa.persistence.PersistenceProviderImpl
>> 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
> --
> Lei Wang (Rex)
> rwonly AT

Lei Wang (Rex)
rwonly AT

View raw message