Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Problem of eclipselink upgrade (2.0.2) - WebLogic


The latest release of Oracle WebLogic Server has been available on OTN at the following location since 20110115.

This release provides support for JSR-317 JPA 2.0 container managed applications using the QWG8 patch or a manual prepending classpath change.

In you were required to use the FilteringClassLoader via the *<wls:prefer-application-packages>* addition to your application managed persistence unit - this workaround as well as the persistence.xml renaming one is now fully deprecated and not required in for both application and container managed persistence contexts. As of 20110115 the 5 outstanding issues below look to be fixed by applying the patch for QWG8 or manually prepending to the WebLogic server classpath.

>A JPA 2.0 EE application using EclipseLink as the JPA2 persistence provider on WebLogic is detailed in the analysis section below
1) JPA 2.0 XSD parsing - verified
2) New JPA 2.0 schema elements like <shared-cache-mode>NONE</shared-cache-mode> - verified 3) JPA 2.0 runtime API like a entityManager.getMetamodel(); call on the Servlet or Stateless session bean - verified 4) JPA 2.0 weaving/instrumentation - this will require a more detailed lazy model and more debugging to fully verify 5) Dependency Injection of a container managed JPA 2.0 entityManager on a EJB component like a stateless session bean - verified

>OTN download
>Supported Oracle WebLogic Server Versions
>TopLink JPA 2.0 Specific documentation/patching
>EclipseLink Wiki: JPA 2.0 using EclipseLink on WebLogic analysis (XSD, Weaving, DI of @PersistenceContext)

thank you
/Michael O'Brien

On 12/05/2010 13:08, Michael O'Brien wrote:
   Hi, received your message, here to help.
I currently see no behavioral change of a standard JTA servlet/ejb container managed EE Application The only difference at the EclipseLink API level is the version change from 1.2 to 2.0 I tested our standard injection mechanism and your JNDI lookup and noted that the following element name changed from "res*" to "resource*" between 10.3.x (Sept 2008) and - check your logs for JNDI failures.

The intermittent NPE's you describe may be related to your EM JNDI lookup, multiple/overrides or no references to our provider jar - maybe try @PersistenceUnit EMF or @PersistenceContext EM injection if you can - for full container managed functionality. Are you using an unmodified server with the following shipped EclipseLink jar %server%/modules/org.eclipse.persistence_1.0.0.0_2-0.jar? Do you have any overrides in the commEnv.cmd script or a global shared library? If you are injecting or doing a lookup of your persistence unit in your WAR - do you have a persistence-context-ref? Our demo application does not require this. Does an application managed (bootstrap) SE RESOURCE_LOCAL persistence unit work at least via emf = Persistence.createEntityManagerFactory("PersistenceName") ... emf.createEntityManager() The only other issue may be that obtaining a container managed entityManager via JNDI lookup may have changed between releases - probably not since this would require a JSR-317 JEE6 spec change. As a quick verification of the move from - I recently upgraded from to this time via the OEPE Oracle Enterprise Pack for Eclipse download which comes preconfigured with Eclipse 3.5 EE and WebLogic

The test scenario involves @EJB injection on a servlet of a @Stateless session bean containing an injected @PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION) transactional JTA (Derby 10.5.3) EntityManager. The basic demo consists of finding existing and persisting new entities. (Different from your InitialContext lookup) See the following page where we are posting any source, configuration details or issues needed to get a small EclipseLink JPA demo running on WebLogic 10.3.x.0

   1) Injection Test Results: OK
The version that ships with this version of is EclipseLink 2.0.2_v20100323 rev# 6872

I am running with the default 32 bit JRockit JVM via 32 bit Eclipse on a 64 bit Windows 7 box. c:\opt\wls10330\JROCKI~1.0-6\bin\java -jrockit -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n -Djava.compiler=NONE -Xms512m -Xmx512m -Dweblogic.Name=AdminServer\opt\wls10330\WLSERV~1.3\server\lib\weblogic.policy -Xverify:none -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.sbconsole... -Dplatform.home=C:\opt\wls10330\WLSERV~1.3 -Dwls.home=C:\opt\wls10330\WLSERV~1.3\server -Dweblogic.home=C:\opt\wls10330\WLSERV~1.3\server -Dwlw.iterativeDev= -Dwlw.testConsole= -Dwlw.logErrorsToConsole= -Dweblogic.ext.dirs=c:\opt\wls10330\patch_wls1033\profiles\default\sysext_manifest_classpath;c:\opt\wls10330\patch_oepe1033\profiles\default\sysext_manifest_classpath;c:\opt\wls10330\patch_ocp353\profiles\default\sysext_manifest_classpath weblogic.Server <12-May-2010 11:58:24 o'clock AM EDT> <Info> <Management> <BEA-141107> <Version: WebLogic Server Fri Apr 9 00:05:28 PDT 2010 1321401 >

   Running the demo Servlet client we read and persist OK

<12-May-2010 11:58:46 o'clock AM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 11:58:46.104--ServerSession(49448095)--EclipseLink, version: Eclipse Persistence Services - 2.0.2.v20100323-r6872> <12-May-2010 11:58:46 o'clock AM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 11:58:46.104--ServerSession(49448095)--Server: WebLogic Server Fri Apr 9 00:05:28 PDT 2010 1321401 > <12-May-2010 11:58:46 o'clock AM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 11:58:46.354--ServerSession(49448095)--file:/F:/view_w35_wls1033/examples/org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB/build/classes/_example login successful> [EL Example]: enterprise: ApplicationService persisting: id: null state: null left: null right: null parent: HashSet@36928089 references: HashSet@36928089) on EM: org.eclipse.persistence.internal.jpa.EntityManagerImpl@2129b5c

   2) JNDI EntityManager lookup OK

As a secondary test I reproduced part of your config by retrofitting my app for mixed @PersistenceContext JNDI lookup instead of pure @PersistenceContext injection and was OK.

@PersistenceContext(name="ApplicationService", unitName="example", type=PersistenceContextType.TRANSACTION) public class ApplicationService implements ApplicationServiceLocal, ApplicationServiceRemote {
   SessionContext sessionContext;
//@PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION) private EntityManager entityManager;

   public EntityManager getEntityManager() {
       if(null == entityManager) {
           try {
entityManager = (EntityManager) sessionContext.lookup("ApplicationService");

new weblogic-ejb-jar.xml
<jndi-name>ApplicationService</jndi-name> </weblogic-enterprise-bean>

<12-May-2010 12:55:45 o'clock PM EDT> <Warning> <EJB> <BEA-010202> <Call-by-reference is not enabled for the EJB 'ApplicationService'. The server will have better performance if it is enabled. To enable call-by-reference, set the enable-call-by-reference element to True in the weblogic-ejb-jar.xml deployment descriptor or corresponding annotation for this EJB.> [EL Example]: enterprise: Action: demo [BaseLocalObject] for EJB: 'ApplicationService' <12-May-2010 12:55:47 o'clock PM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 12:55:47.658--ServerSession(35328003)--EclipseLink, version: Eclipse Persistence Services - 2.0.2.v20100323-r6872> <12-May-2010 12:55:47 o'clock PM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 12:55:47.658--ServerSession(35328003)--Server: WebLogic Server Fri Apr 9 00:05:28 PDT 2010 1321401 > <12-May-2010 12:55:47 o'clock PM EDT> <Notice> <EclipseLink> <BEA-2005000> <2010-05-12 12:55:47.658--ServerSession(35328003)--file:/F:/view_w35_wls1033/examples/org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB/build/classes/_example login successful> [EL Example]: enterprise: ApplicationService persisting: id: null state: null left: null right: null parent: HashSet@33933055 references: HashSet@33933055) on EM: org.eclipse.persistence.internal.jpa.EntityManagerImpl@2984a10

Note: as a verification that my JNDI lookup retrofitted app actually required the lookup and was not still deferring to dependency injection - I commented out the lookup

entityManager = (EntityManager) sessionContext.lookup("ApplicationService");
   ...and got an expected NPE on any getEntityManager() call


So JNDI lookups seem to work, however this is probably not your issue since your app runs some of the time. If you post the full stacktrace and configuration of your EE application we can help out further.

   thank you

Kentaro Uesugi wrote:
Hi experts.

I have been facing EclipsLink problem as following. Any sharing is appreciate.

Because of eclipsLink upgrade, I have changed to  use a server from
WebLogic including "EclipsLin 1.2.0" to WebLogic10.3.3.0
including "EclipsLink2.0.2."

With WebLogic, our system had been worked without any problem.
However, since I have changed to WebLogic10.3.3.0 including
EclipsLink2.0.2, I got a problem as following.

As I run a program, I get three kinds of cases which comes out
randomly. (I get a different result each time)

  case 1. work normal

case 2. error: the message said "JNDI lookup error becasue of EM is null."
    I used this code following.
     --> (EntityManager)ctx.lookup("java:comp/env/PersistenceName");

  case 3.error: the message said "NullPointerException casued at
   I used this code following.
     --> ServerSession serverSession =

 I am not sure about the cause of those problems above due to the
EclipsLink upgrade or not. Any sharing is appreciate.

eclipselink-users mailing list

Back to the top