EclipseLink/Development/JPA 2.0/weblogic

Running JPA 2.0 API on WebLogic 10.3

• This document details a solution for enabling JPA 2.0 API functionality for the following scenarios.
• 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
  • 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.

Design

Design Issue 1: JSR-317 JPA 2.0 EJB 3.1 Support

DI 1: Problem

• The modules currently shipped with WebLogic 10.3.2.0 (Patch Set 1) in are the following JPA 1.0 compatible versions - these must be overriden in order to run JPA 2.0 API.
  • modules/org.eclipse.persistence_1.0.0.0_1-2-0.jar
  • modules/javax.persistence_1.0.0.0_1-0-2.jar

DI 1: Alternative 1: Manual overwrite of eclipselink and javax.persistence libraries in modules

• Current solution - this should be deprecated.

DI 1: Alternative 2: Reference higher in the server classpath via commEnv.cmd

• Workable solution but it has issues
  • 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: 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: Alternative 3: Application Level Shared Library

• 20091202 - scope is not large enough - deprecated.

DI 1: Alternative 4: Global Level Shared Library

• 20091202 - in progress
• 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.
• see http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming/classloading.html

DI 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.

• Potential modification to weblogic.xml:weblogic-install is (without $ variable prefix)

  <copy file="F:/view_w35d/jpa/plugins/javax.persistence_2.0.0.v200911041116.jar" todir="${weblogic.domain}/lib"/>

• Another issue to solve is the absence of OSGI functionality - fixed by adding TBD

<2-Dec-2009 1:09:45 o'clock PM EST> <Notice> <WebLogicServer> <BEA-000395> <Following extensions directory contents added to the end of the classpath:
C:\opt\wls10320\user_projects\domains\base_domain\lib\eclipselink.jar;C:\opt\wls10320\user_projects\domains\base_domain\lib\javax.persistence_2.0.0.v200911041116.jar;F:\view_w35d\jpa\plugins\javax.persistence_2.0.0.v200911041116.jar> 
<2-Dec-2009 1:09:45 o'clock PM EST> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: 
java.lang.NoClassDefFoundError: org/osgi/framework/BundleActivator
java.lang.NoClassDefFoundError: org/osgi/framework/BundleActivator

DI 1: Alternative 6: Use -Dweblogic.ext.dirs override

• Like alternative #5 - this one is also appended to the end of the server classpath - so is not of use.

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

@Local @Stateless
public class ApplicationService implements ApplicationServiceLocal {
	@PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION)	
	private EntityManager entityManager;