Community
Participate
Working Groups
>Currently the 10.3.2.0 version of WebLogic is JPA 1.0 compliant - it requires some configuration to run JPA 2.0 API code >Tested standalone functionality using the EAR with JPA 2.0 Metamodel functionality from the wiki tutorial at http://wiki.eclipse.org/EclipseLink/Examples/JPA/WebLogic_Web_Tutorial >We get an expected CNFE as a verification of out-of-the-box state javax.ejb.EJBException: EJB Exception: : java.lang.NoSuchMethodError: getMetamodel at org.eclipse.persistence.example.jpa.server.business.ApplicationService.getMetamodel(ApplicationService.java:85)
>Fix For both fixes - we will use the undated jar in the plugin directory at F:\view_w35d\jpa\plugins >Standalone Fix C:\opt\wls10320\wlserver_10.3\common\bin\commEnv.cmd From set WEBLOGIC_CLASSPATH=%JAVA_HOME%\lib\tools.jar... To set WEBLOGIC_CLASSPATH=F:/view_w35d/jpa/plugins/javax.persistence_2.0.0.v200911041116.jar;%JAVA_HOME%\lib\tools.jar... >Results from http://xps435:7001/enterprise/FrontController?action=demo ---------------- JPA 2.0 Metamodel: MetamodelImpl@6298392 [ 3 Types: , 1 ManagedTypes: , 1 EntityTypes: , 0 MappedSuperclassTypes: , 0 EmbeddableTypes: ] >eclipselink.jpa.test server tests Fix F:\view_w35d\jpa\eclipselink.jpa.test <target name="weblogic-start-nosleep"> add <pathelement location="../plugins/javax.persistence_2.0_preview.jar"/> - and fix the reference to junit.jar >added JPA 2.0 metamodel code to NullBindingJUnitTestCase.testNullifyBigDecimal() >ran F:\view_w35d\jpa\eclipselink.jpa.test>ant server-test-datatypes >Results ---------------- Query: DataModifyQuery(sql="CREATE TABLE CMP3_PBYTEARRAY_SEQ (SEQ_NAME VARCHAR2(50) NOT NULL, SEQ_COUNT NUMBER(38) NULL, PRIMARY KEY (SEQ_NAME))") _Metamodel: MetamodelImpl@24809835 [ 30 Types: , 7 ManagedTypes: , 7 EntityTypes: , 0 MappedSuperclassTypes: , 0 EmbeddableTypes: ] [EL Info]: 2009-11-26 12:23:06.657--ServerSession(3671545)--file:/C:/opt/wls10320/wlserver_10.3/samples/domains/eclipselink/servers/myserver/tmp/_WL_ ser/eclipselink-datatypes-model/knamj3/eclipselink-datatypes-model_ejb.jar-default logout successful >pending work - wiki documentation changes to document how to end the 5xx mb java.exe server process to avoid the .lok error when restarting the server server started in separate jpa/eclipselink.jpa.test project can be run directly from startWebLogic.cmd - code review checkin of weblogic.xml changes - there is an issue with using a relative path - as the tests only run JPA 2.0 code when the server is started outside of the test scripts (the fix to weblogic.xml is insufficient)
Created attachment 153192 [details] weblogic.xml server tests path addition for JPA 2.0 API configuration
>path problem is because the JPA 2.0 jar is too low in the classpath when run from the script (weblogic.jar is above it) >script - not-working java.class.path = C:\opt\wls10320\wlserver_10.3\server\lib\weblogic.jar;F:\view_w35d\jpa\plugins\javax.persistence_2.0.0.v200911041116.jar;C:\opt\wls10320\jrockit_160_14_R27.6.5-32\lib\tools.jar >standalone - working java.class.path = c:\opt\wls10320\patch_wls1032\profiles\default\sys_manifest_classpath\weblogic_patch.jar;F:/view_w35d/jpa/plugins/javax.persistence_2.0.0.v200911041116.jar;c:\opt\wls10320\JROCKI~1.5-3\lib\tools.jar;c:\opt\wls10320\utils\config\10.3\config-launch.jar;C:\opt\wls10320\WLSERV~1.3\server\lib\weblogic_sp.jar;C:\opt\wls10320\WLSERV~1.3\server\lib\weblogic.jar;c:\opt\wls10320\modules\features\weblogic.server.modules_10.3.2.0.jar;C:\opt\wls10320\WLSERV~1.3\server\lib\webservices.jar;c:\opt\wls10320\modules\ORGAPA~1.0/lib/ant-all.jar;c:\opt\wls10320\modules\NETSFA~1.0_1/lib/ant-contrib.jar;C:\opt\wls10320\WLSERV~1.3\common\eval\pointbase\lib\pbclient57.jar;C:\opt\wls10320\WLSERV~1.3\server\lib\xqrl.jar
>2 issues fixed 1) There are 3 ways to add the javax.persistence 2.0 jar to WebLogic a) replace the 1.0 jar - and behave like GlassFish v3 - not a good option because we will modify the clients modules directory b) create shared-library - this will require changing the way we push the built eclipselink.jar as both will need to be in the shared library - currently we replace the eclipselink.jar in modules c) add JPA 2.0 jar above the 1.0 jar in the server classpath Solution: this is what we are currently doing - it is above weblogic.jar 2) The isJPA10() call in all JPA 2.0 tests returns true if it finds the JPA 1.0 jar - even if the 2.0 jar exists. Therefore this test is not valid for a server configuration where there are 2 versions of the javax.persistence jar in the classpath. We can fix this by adding a property flag.
Created attachment 153205 [details] Add JPA 2.0 javax.persistence library higher in server classpath library - option 3 of 3 >This patch represents a working solution where we append the JPA 2.0 library higher in the classpath than the existing 1.0 jar (we cannot replace it) >The next option under investigation is to move to a shared-library that will override both the following jars in the modules directory javax.persistence_1.0.0.0_1-0-2.jar org.eclipse.persistence_1.0.0.0_1-2-0.jar
>Criteria tests all pass under weblogic 10.3.2.0 - it turns out that the eclipselink jar in modules needs to be manually replaced before running server testing. [junit] Running org.eclipse.persistence.testing.tests.jpa.criteria.CriteriaServerTestSuite [junit] Tests run: 201, Failures: 0, Errors: 0, Time elapsed: 55.942 sec I think the case for a shared-library method (option b) is even better in this case as we would be able to automatically update the eclipselink jar if both it and the javax.persistence jar were packaged together as a shared-library - solving both issues.
>Currently investigating use of the following in a global shared library to override the modules directory classpath level http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming/classloading.html public class weblogic.utils.classloaders.FilteringClassLoader extends weblogic.utils.classloaders.GenericClassLoader
Can a domain extension template be used similar to how we add the spatial and XML DB libraries?
>The following weblogic-application.xml markup using the prefer-application-packages element in the ear descriptor overrides the modules directory in conjuction with the FilteredClassLoader - the only issue I have is a ClassCastException because of how I am positioning the 2 jars. <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> Caused By: weblogic.deployment.EnvironmentException: Error processing persitence unit example of module org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB.jar: Error instantiating the Persistence Provider class org.eclipse.persistence.jpa.PersistenceProvider of the PersistenceUnit example: java.lang.ClassCastException: org.eclipse.persistence.jpa.PersistenceProvider >I suspect I need to modify our SPI code to use the FCL >I will checkout the domain extension lib case
>The domain lib override alternative will not work because this lib is below the server classpath and has no effect after 10.3.0. http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/weblogic#DI_1:_Alternative_5:_Domain_Extension_Template 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 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.
>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;
>The following now works for an application managed EAR (containing only a WAR - no ejb.jar) - I no longer get a CCE >prerequisites: unmodified modules directory with a shiped EclipseLink 1.2 jar (with JPA 2.0 implementation API) and a javax.persistence JPA 1.0 jar (no JPA 2.0 interfaces) >The JPA 2.0 impl and spec jars are referenced both as shared-libraries and packaged with the EAR. >log: [EL Example]: enterprise: JPA 2.0 Metamodel: MetamodelImpl@7994123 [ 3 Types: , 1 ManagedTypes: , 1 EntityTypes: , 0 MappedSuperclassTypes: , 0 EmbeddableTypes: ] >config: - no wls:library-ref in weblogic-application.xml - prefer-application-packages set for both javax.persistence and org.eclipse.persistence in weblogic-application.xml - persistence.xml is JTA with container-managed DS (must test application-managed datasource) and RESOURCE_LOCAL with non-JTA jdbc connection - no persistence-context-ref in web.xml - 2 shared libraries defined in Eclipse for weblogic deployment - but only older eclipselink 2.0 version visible in summary of deployments console page http://localhost:7001/console/console.portal?_nfpb=true&_pageLabel=AppDeploymentsControlPage >We have 2 ways to define the libary override here 1 - per EAR 2 - global library referenced by each EAR >Todo: - verify combined and separate EAR defined and shared-library deployment defined scenarios - test boostrap and @PersistenceUnit injection on the servlet of the EMF (currently bootstrap Persistence.createEntityManagerFactory(puName);)
Created attachment 153747 [details] Preliminary example EAR - application managed EM, container managed JTA DS, bootstrap EMF (option 3 of 6 - UC 1 of 4) - add eclipselink.jar to app-lib (5Mb)
>4h to reproduce the WebLogic 10.3.2.0 and EclipseLink 2.0 combination with a clean EAR on a separate machine (to avoid any possible leftover configuration that could skew results) I have a full procedure for 1 of the 4 supported use cases documented at the following URL - the other 3 will use slight variants of this one. http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/weblogic#DI_1:_Alternative_3:_Application_Level_Shared_Library_-_In_Use
Created attachment 153796 [details] Alternative #3 EAR (add 5mb eclipselink jar beside jpa2 spec jar before deployment)
Created attachment 153797 [details] Alternative #3 WAR Eclipse project
>The above 2 eclipse projects implement the procedure below This procedure requires "no" changes to the server - we can place any library jar higher in the server classpath (modules directory) with the following... This particular case is for an EAR containing only an application managed EM in a WAR, the other use cases involving other forms of application managed and container managed EM's that may involve a separate shared-library EAR on the server are in progress for our particular case. >Do all all of the following... - .MANIFEST reference to the jars - <wls:prefer-application-packages> package overrides in weblogic-application.xml - no web.xml persistence-context-ref - no weblogic-application.xml wls:library-ref - no global shared-library EAR on the server - jars placed in the EAR project under APP-INF/lib >We need to respond to the following forum post with this procedure http://forums.oracle.com/forums/thread.jspa?messageID=3946206� >The next step is to prototype a version for alternative #4 (global shared library via console)
>The procedure on this wiki will require formal documentation on the ELUG >The modification to weblogic.xml to enable the eclipselink and javax.persistence jar override per deployment for our jpa test suite can be made by VE or myself depending on priorities.
Including Yiping
>This bug is being passed on to VE to do the weblogic.xml modifications for our test scripts See the verified alternative #3 procedure on the wiki site. I will expand on #4 next week in the wiki as a secondary alternative. The investigation part of this enhancement is complete. >unassigning obrien, assigning back to default
Moving these bugs to 2.0.1 since 2.0 is shipping today. If the issue is resolved for 2.0 please change the target back when you close the bug.
>Reassiging to myself as I do some follow up from the design review/demo on 20091218 - debug how the proxy handles 2.0 functions through a container managed app using the weblogic server source passed to us - review detailed weaving support in container and application managed cases - verify JPA 2.0 tags in persistence.xml using 2.0 XSD like <shared-cache-mode>NONE</shared-cache-mode> - modify cases to use a separate utility.jar containing only entities - option 3 is still valid
Created attachment 156842 [details] unofficial experimentation details and logs
>this experimentation work is complete based on all the application managed and container managed testing scenarios worked out here - several procedural and code changes to the test suite infrastructure has been worked out with the test engineering group, the code changes have been reviewed, see part of them in http://fisheye2.atlassian.com/changelog/eclipselink/?cs=6339
>A discussion on a CM or AM app using a 2.0 schema version header continues in bug # 331569
>This bug is deprecated by bug # 334468
>A WebLogic 10.3.3.0 user not yet on 10.3.5.0 http://old.nabble.com/FW%3A-Eclipselink-2---JPA-2-with-WebLogic-10.3.3-to33281550.html
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
