Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EclipseLink/Development/JPA 2.0/weblogic
< EclipseLink | Development | JPA 2.0
Revision as of 09:52, 10 December 2009 by Unnamed Poltroon (Talk) (→DI 1: Alternative 3: Application Level Shared Library - In Use)
Contents
- 1 Running JPA 2.0 API on WebLogic 10.3
- 1.1 Problem
- 1.2 Analysis
- 1.3 Design
- 1.3.1 Design Issue 1: JSR-317 JPA 2.0 EJB 3.1 Support
- 1.3.1.1 DI 1: Problem
- 1.3.1.2 DI 1: Alternative 1: Manual overwrite of eclipselink and javax.persistence libraries in modules
- 1.3.1.3 DI 1: Alternative 2: Reference higher in the server classpath via commEnv.cmd
- 1.3.1.4 DI 1: Alternative 3: Application Level Shared Library - In Use
- 1.3.1.5 DI 1: Alternative 4: Global Level Shared Library
- 1.3.1.6 DI 1: Alternative 5: Domain Extension Template
- 1.3.1.7 DI 1: Alternative 6: Use -Dweblogic.ext.dirs override
- 1.3.1 Design Issue 1: JSR-317 JPA 2.0 EJB 3.1 Support
- 1.4 Implementation
- 1.5 Log
- 1.6 Resources
Running JPA 2.0 API on WebLogic 10.3
- We want a way for end users to override the JPA 1.0 library shipped with WebLogic Server 10.3.2.0 without modifying the server and affecting other applications.
- For a single EAR use alternative #3 below.
Problem
- This document details a solution for enabling JPA 2.0 API functionality for various enterprise application use cases involving application managed EntityManagers.
- 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
- 1) End users of WebLogic 10.3.2.0
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.
Use Cases
- Use case partitioning criteria
- Application managed EM
- @PersistenceUnit EMF or static bootstrap Persistence.createEntityManagerFactory EMF
- Global scoped datasource
- UC 1 : JTA global scoped datasource - alternative #3
- UC 2 : non-JTA global scoped datasource
- UC 3 : RESOURCE_LOCAL jdbc connector
- Application scoped datasource
- UC 11 : JTA global scoped datasource
- UC 12 : non-JTA global scoped datasource
- UC 13: RESOURCE_LOCAL jdbc connector
- Global scoped datasource
- @PersistenceUnit EMF or static bootstrap Persistence.createEntityManagerFactory EMF
- Container managed EM
- @PersistenceUnit EMF and/or @PersistenceContext EM injection on session bean
- Global scoped datasource
- UC 21 : JTA global scoped datasource
- UC 22 : non-JTA global scoped datasource
- UC 23 : RESOURCE_LOCAL jdbc connector - invalid
- Application scoped datasource
- UC 31 : JTA global scoped datasource
- UC 32 : non-JTA global scoped datasource
- UC 33 : RESOURCE_LOCAL jdbc connector - invalid
- Global scoped datasource
- @PersistenceUnit EMF and/or @PersistenceContext EM injection on session bean
- Application managed EM
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
- change
- 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.
This example uses an aplication-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
- 2b) Add the JPA 2.0 specification jar - this will override javax.persistence_1.0.0.0_1-0-2.jar.
- 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
- 5) Add the prefer-application-packages element to weblogic-application.xml so the internal WebLogic API FilteredClassLoader places our library ahead of the modules directory.
<wls:prefer-application-packages> <wls:package-name>javax.persistence.*</wls:package-name> <wls:package-name>org.eclipse.persistence.*</wls:package-name> </wls:prefer-application-packages>
- 6) The EMF is either EE injected or obtained via a static Persistence call
@PersistenceUnit(unitName="example") private EntityManagerFactory emf; or private EntityManagerFactory emf; emf = Persistence.createEntityManagerFactory("example);
- 7) The following configuration elements are not present in this procedure
- - no web.xml persistence-context-ref
- - no weblogic-application.xml 'wls:library-ref
- - no global shared-library EAR on the server either via the console or via the Eclipse IDE.
- Note: at this time there is no requirement to add WebLogic platform specific handling for the FilteredClassLoader - we are ok with the XML EAR deployment descriptor change.
Output 3
- 20091202 - in progress
- See WebLogic Help http://localhost:7001/consolehelp/console-help.portal?_nfpb=true&_pageLabel=page&helpId=library.DeployLibrary
- See WebLogic documentation http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming/classloading.html#wp1097064
- 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.
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 editing the .MANIFEST - see bug# 296733
<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.
- base_domain/bin/startWebLogic.cmd
- JAVA_OPTIONS=%JAVA_OPTIONS% -Dweblogic.ext.dirs=F:/view_w35d/jpa/plugins/javax.persistence_2.0.0.v*.jar
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.
- See the development bug #296271 for attached EAR test archives.
Container Managed Clients
- Support for container managed 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.
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;