Revision as of 22:23, 16 January 2011

Running JPA 2.0 API on WebLogic 10.3

DISCLAIMER: This page reflects investigation into how EclipseLink users can evaluate EclipseLink JPA 2.0 within existing WebLogic releases. It does NOT imply any formal certification from Oracle that JPA 2.0 is supported on WebLogic at this time.

20110115: JPA 2.0 using EclipseLink on WebLogic 10.3.4.0

This section on WebLogic 10.3.4 was added to the original document that discussed experimental methods of getting a JPA 2.0 based application running on WebLogic 10.3.3.0 - that section is now deprecated with the release of WebLogic 10.3.4.0 on 14 Jan 2011.

20100115-Note: the three outstanding issues (XSD, Weaving and JPA 2.0 Dependency Injection) look to be fixed by applying patch QWG8 or manually prepending to the server classpath.

WebLogic 10.3.4.0 is released on OTN - the contents of this page will likely be deprecated as specific to 10.3.3.0 - pending a full review next week.

There is a large list of public OTN and EclipseLink wiki pages, bug/enhancement analysis comments and newsgroup entries that we are now able to discuss. A full review of all 10.3.3.0 workarounds, updates to all WebLogic JPA 2.0 tutorial configurations and responses to all open WebLogic related JPA classloader and XSD validation issues is in order. I have prepared a list of these over the last year.

In 10.3.3.0 you were required to use the FilteringClassLoader via the <wls:prefer-application-packages> addition to your application managed persistence unit - this workaround is now deprecated and not required in 10.3.4.0 for both application and container managed persistence contexts.

Essentially in order to enable JPA 2.0 functionality on WebLogic 10.3.4 shipped on 14 Jan 2011 - you apply the patch below or manually edit your server classpath to put the JPA 2.0 persistence specification API jar and the +com.oracle.jpa2support_1.0.0.0_2-0.jar+ ahead of the other liibraries on the classpath.

set BEA_HOME=c:\opt\wls10340_pub110115
# patch for 10.3.4
set PRE_CLASSPATH=%BEA_HOME%\modules\javax.persistence_1.0.0.0_2-0-0.jar;%BEA_HOME%\modules\com.oracle.jpa2support_1.0.0.0_2-0.jar

Everything is shipped with WebLogic 10.3.4 but JPA 1.0 is enabled by default so that this JEE5 capable server is backwards compatible with JEE5/JPA1 out of the box. Without the above patch you will see the following.

20100115-Note: this issue is fixed by applying patch QWG8 or manually prepending to the server classpath.

We have the required bundles in the modules directory but the JPA 2.0 specification jar is not above the JPA 1.0 jar by default - the patch will change this...

javax.persistence_1.0.0.0_2-0-0.jar (upgraded from 1-0-2)

org.eclipse.persistence_1.0.0.0_2-1.jar (upgraded from 2-0)

A very quick test of a JPA 2.0 container managed app with the following persistence.xml in the ejb.jar works as detailed below - before the patch is applied.

Note: All testing at this time is on a WebLogic 10.3.4.0 install out-of-the-box (without the QWG8 patch - to verify default JPA 1.0 functionality). The only modification I made yet was in creating a derby 10.5.3.0 JTA global datasource "localJTA" on the server - and drop a container managed JPA 2.0 app as an EAR in the autodeploy directory on the default user domain.

or 3) The same exception if we try to run JPA 2.0 on the DI entityManager from the SSB in the EJB container classLoader

javax.ejb.EJBException: EJB Exception:: java.lang.NoSuchMethodError: javax/persistence/EntityManager.getMetamodel()Ljavax/persistence/metamodel/Metamodel;
at org.eclipse.persistence.example.jpa.server.business.ApplicationService.insertObjects(ApplicationService.java:66)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
..
at $Proxy74.insertObjects(Unknown Source)
at org.eclipse.persistence.example.jpa.server.business.ApplicationService_5ptwty_ApplicationServiceLocalImpl.__WL_invoke(Unknown Source)

JPA 2.0 Container Bytecode Weaving/Instrumentation

20100115-Note: the three outstanding issues (XSD, Weaving and JPA 2.0 Dependency Injection) look to be fixed by applying patch QWG8 or manually prepending to the server classpath.

We also get the Kodo/OpenJPA provider when we attempt to weave.

<openjpa-1.1.1-SNAPSHOT-r422266:965591 fatal user error> org.apache.openjpa.util.MetaDataException:"org.eclipse.persistence.example.jpa.server.business.Cell.id" declares generator name "EL_SEQUENCE_CELL", but uses the AUTO generation type. The only valid generator names under AUTO are "uuid-hex" and "uuid-string".
at org.apache.openjpa.persistence.AnnotationPersistenceMetaDataParser.getGeneratedValueStrategy(AnnotationPersistenceMetaDataParser.java:1226)

Therefore there is still a little bit of configuration required.

Enabling JPA2 support

1) Install Oracle WebLogic 10.3.4 or upgrade from 10.3.3

1) Install the QWG8 patch, or

2) manually add the com.oracle.jpa2support_1.0.0.0_2-0.jar ahead of the server classpath by following the instructions in the documentation at

Older 10.3.3.0 content

20100115-Note: the three outstanding issues (XSD, Weaving and JPA 2.0 Dependency Injection) look to be fixed by applying patch QWG8 or manually prepending to the WebLogic 10.3.4.0 server classpath.

WebLogic 10.3.2.0 and 10.3.3.0 ship with the JPA 1.0 specification jar - we would like to run JPA 2.0 API on WebLogic. This document describes a potential solution to container-managed and application managed deployments and the details in getting their use cases running.

Results Matrix

The following table summarizes the type of test, server modifications and results for verious container managed and application managed EntityManager deployments on WebLogic server.

Problem

The page is geared to both end users and internal eclipselink.jpa.test server test implementors.

1) End users of WebLogic 10.3.2.0

This involves configuring the server for JPA 1.0 permanently or per-deployment

Note: This procedure is for application managed deployments - container managed injection will still default to JPA 1.0 for servers that do not ship with 2.0 out of the box

2) EclipseLink JPA test users on WebLogic 10.3.2.0

This involves temporarily configuring the server per-test-deployment

Analysis

EclipseLink 1.2 and 2.0+ fully implement the JPA 2.0 specification via enhancement # 248291 and are the RI for the GlassFish V3 JEE6 server. In order to use this functionality the 2.0 version of the JPA specification jar - javax.persistence.jar must be added higher in the WebLogic server classpath see enhancement # 296271.

Now, you may have noticed that the modules/org.eclipse.persistence_1.0.0.0_1-2-0.jar jar contains JPA 2.0 API implementation classes such as org.eclipse.persistence.internal.jpa.metamodel - however this API is not available through interface classes (because only the javax.persistence 1.0 jar is present) and we also are missing the services file for Criteria/Metamodel - in any case a predeploy should fail where the EAR contains JPA 2.0 API out of the box.

The server now runs a single version of the two libraries for all applications - this may not be compatible with older applications or other JPA providers running on the server.

DI 1.1: Solution

In <WEBLOGIC_HOME>\wlserver_10.3\common\bin\commEnv.cmd

change

set WEBLOGIC_CLASSPATH=%JAVA_HOME%\lib\tools.jar...

To

set WEBLOGIC_CLASSPATH=F:/view_w35d/jpa/plugins/javax.persistence_2.0.0.*.jar;%JAVA_HOME%\lib\tools.jar...

where F:/view_w35d == %SVN_TRUNK

Note: do not use the javax.persistence_2.0_preview.jar - the dated javax.persistence_2.0.0.*.jar one is the final PFD version for the JPA 2.0 specification.

DI 1.1: Alternative 3: Application Level Shared Library - In Use

20100115-Note: the three outstanding issues (XSD, Weaving and JPA 2.0 Dependency Injection) look to be fixed by applying patch QWG8 or manually prepending to the WebLogic 10.3.4.0 server classpath.

This example uses an application-managed EE injected EMF.

20091202 working standalone Eclipse EAR (WAR only) prototype attached bug 296271 - this procedure has been verified on 2 separate servers on separate machines (in order to filter out any possible leftover configuration experimentation that could skew results)

The following artifacts and modifications are required (failure of any one of these will result in a Persistence Unit not found during deployment or runtime)

1) Start with an EAR project containing only a WAR (no ejb-jar) - Eclipse can generate one for you after you install the WebLogic Eclipse Plugin

2) Ship EclipseLink 2.0 and JPA 2.0 in the EAR project (not the WAR)

2a) Add eclipselink.jar V2 (OSGI version is org.eclipse.persistence_1.0.0.0_2-0-0.jar) to EarContent\APP-INF\lib - this will override org.eclipse.persistence_1.0.0.0_1-2-0.jar in the modules dir on the server

3) Update the .MANIFEST where the root of the entity classes managed by the EntityManager reside (here the src\META-INF off the WAR) to point to these included jars (relative paths not required if they are in the classpath - which they are)

Class-Path: javax.persistence_2.0.0.v200911041116.jar eclipselink.jar

4) Place your persistence.xml descriptor as usual for an application-managed entityManager in the WAR also at the classes root in src\META-INF - this will be exported to the server as classes. (Normally for a container-managed entityManager we would place persistence.xml and all entities in the ejb jar)

4a) make sure to modify the Entity package paths as we are dealing with an SE persistence unit here

We need to respond to the post about the FilterClassLoader with the procedure on creating a shared library for JPA 2.0 and EclipseLink 2.0 that is above the modules directory on WebLogic classpath.

In this scenario we will require the creation of an EAR deployment application that can be referenced from any other EAR application that requires the EclipseLink override.

DI 1.1: Alternative 5: Domain Extension Template

20091202 - This one suggested by Doug - similar to what is done for other vendor libraries.

This method involves copying the JPA 2.0 libraries to the lib directory off the current domain

example: %WEBLOGIC_HOME%\user_projects\domains\base_domain\lib

is below

%WEBLOGIC_HOME%\modules

The domain lib override alternative will not work because this lib is below the server classpath and has no effect after 10.3.0.

Our current weblogic.xml test script copies the xdb, spatial, jdbc, junit, xmlparserv2 and trunk eclipselink.jar to the domain lib - however this only works if no library is in modules that will override these domain libs.

Since 10.3.1 the user still needs to apply a patch to override modules libs in these lib cases.
Therefore this option is deprecated for 10.3.1 and 10.3.2 since we started shipping with the eclipselink jar.

This UC/DI 21 will detail how to enable full JPA 2.0 functionality for container managed entityManagers.

DI 21: Alternative 1:

DI 1.3:

DI 1.3: Alternative 1:

DI 1.4:

DI 1.4: Alternative 1:

Implementation

Application Managed Clients

The shared-library approach has been prototyped as Alternative #3 and functions fine for EARs that utilize application managed entitymanagers - the Eclipse 1.2 and JPA 1.0 libraries shipped with WebLogic 10.3.2.0 are overriden by the supplied EclipseLink 2.0 and JPA 2.0 libraries in the EAR.

Container Managed EM Clients

Support for container managed EM applications is as-is with out of the box JPA 1.0 API functionality - however the alternatives above give WebLogic server administratiors options for setting the JPA 2.0 specification library ahead of the shipped 1.0 jar in the server classpath.

Eclipse IDE Project Details

When creating an EAR project in Eclipse that targets a WebLogic runtime and uses JPA 2.0 functionality - you will receive a compile error on the new JPA 2.0 interface changes for EntityManager and EntityManagerFactory unless you put the JPA 2.0 specification library higher in your compile classpath than the default WebLogic Container Libraries.

Log

20091201: Start investigation

20091202: Scope of this issue has been reduced to the application managed EAR level - @PersistenceContext injection of a 2.0 EM is not supported for EE servers that do not support JPA 2.0 out of the box.

The example used for EAR testing uses a container-managed EM via the following injected bean - this will be modified