geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [Discussion] JPA Pluggability
Date Wed, 06 Apr 2011 06:04:47 GMT
Hi Rex,

It looks to me from the spec that it's fine to do this for each persistence provider and jdbc
driver:

1. create a maven project to bundleize the jar, like we have in our "bundle" projects
2. install the result in g. however we want, such as assembling a server that includes it.
3. include whatever package imports are actually needed for the enhanced application classes
to work in the geronimo plan for the app.

This might not be the most user friendly possible approach, but it looks like it complies
with the requirements and doesn't require any coding on our part.  

Assuming this approach is spec compliant, I would rather wait a bit on anything fancier until
we know what the geronimo deployment plans are going to look like.
There might be an osgi spec under development on how to deal with enhancing classes.  If it
exists and is accessible it might be worthwhile to see if it has anything to offer.

What do you think?

thanks
david jencks

On Apr 5, 2011, at 7:19 PM, Rex Wang wrote:

> typo..
> ejb-3_0-fr-spec-persistence.xml  -> ejb-3_0-fr-spec-persistence.pdf
> http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html
> 
> 2011/4/6 Rex Wang <rwonly@gmail.com>
> 
> 2011/4/6 David Jencks <david_jencks@yahoo.com>
> 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 https://issues.jboss.org/browse/JBAS-9040
> 
>  
> 
> 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 apache.org
> 
> 
> 
> 
> -- 
> Lei Wang (Rex)
> rwonly AT apache.org
> 
> 
> 
> -- 
> Lei Wang (Rex)
> rwonly AT apache.org


Mime
View raw message