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 <[email protected]> > > 2011/4/6 David Jencks <[email protected]> > >> 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
