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 10.3.3.0 
Kentaro,
The latest release of Oracle WebLogic Server has been available on OTN at the following location since 20110115. 
http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-main-097127.html
This release provides support for JSR-317 JPA 2.0 container managed applications using the QWG8 patch or a manual prepending classpath change. 
http://forums.oracle.com/forums/thread.jspa?messageID=9288278?
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 as well as the persistence.xml renaming one is now fully deprecated and not required in 10.3.4.0 for both application and container managed persistence contexts. As of 20110115 the 5 outstanding issues below look to be fixed by applying the http://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#EJBAD1309 patch for QWG8 or manually prepending to the WebLogic 10.3.4.0 server 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
>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 
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/weblogic#Enabling_JPA2_support

>OTN download
http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-main-097127.html
>Patching
http://download.oracle.com/docs/cd/E18476_01/doc.220/e18480/weblogicchap.htm
>Documentation
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13852/toc.htm
>Supported Oracle WebLogic Server Versions
http://download.oracle.com/docs/cd/E15315_06/help/oracle.eclipse.tools.weblogic.doc/html/SupportedServerVersions.html
>TopLink JPA 2.0 Specific documentation/patching
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#EJBAD1309
>EclipseLink Wiki: JPA 2.0 using EclipseLink on WebLogic analysis (XSD, Weaving, DI of @PersistenceContext) 
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/weblogic#Enabling_JPA2_support

thank you
/Michael O'Brien
http://www.eclipselink.org


On 12/05/2010 13:08, Michael O'Brien wrote:

Kentaro,
   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 10.3.3.0 - check your logs for JNDI failures. 
       old
           <res-env-ref-name>example</res-env-ref-name>
       new
           <resource-env-ref-name>example</resource-env-ref-name>
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 10.3.2.0 - I recently upgraded from 10.3.2.0 to 10.3.3.0 this time via the OEPE Oracle Enterprise Pack for Eclipse download which comes preconfigured with Eclipse 3.5 EE and WebLogic 10.3.3.0.
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
http://wiki.eclipse.org/EclipseLink/Examples/JPA/WebLogic_Web_Tutorial#Oracle_WebLogic_Server_10.3.3.0 


   1) Injection Test Results: OK
---------------------
The version that ships with this version of 10.3.3.0 is EclipseLink 2.0.2_v20100323 rev# 6872 http://fisheye2.atlassian.com/changelog/eclipselink/?cs=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 -Djava.security.policy=C:\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.broker... -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 -Dweblogic.management.discover=true -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 10.3.3.0 Fri Apr 9 00:05:28 PDT 2010 1321401 > 

   Running the demo Servlet client we read and persist OK
http://127.0.0.1:7001/enterprise/FrontController?action=demo
<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 10.3.3.0 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: org.eclipse.persistence.example.jpa.server.business.Cell@36928082( 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. 

@Local
@Remote
@Stateless
@PersistenceContext(name="ApplicationService", unitName="example", type=PersistenceContextType.TRANSACTION) public class ApplicationService implements ApplicationServiceLocal, ApplicationServiceRemote { 
   @Resource
   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
<weblogic-ejb-jar>
   <weblogic-enterprise-bean>
       <ejb-name>ApplicationService</ejb-name>
....
       <resource-description>
           <res-ref-name>example</res-ref-name>
           <jndi-name>example</jndi-name>
       </resource-description>
       <resource-env-description>
           <resource-env-ref-name>example</resource-env-ref-name>
           <jndi-name>example</jndi-name>
       </resource-env-description>
<jndi-name>ApplicationService</jndi-name> </weblogic-enterprise-bean> 
</weblogic-ejb-jar>
<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 10.3.3.0 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: org.eclipse.persistence.example.jpa.server.business.Cell@33933048( 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

java.lang.NullPointerException
at org.eclipse.persistence.example.jpa.server.business.ApplicationService.query(ApplicationService.java:83)
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
   /michael
   www.eclipselink.org


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 10.3.2.0 including "EclipsLin 1.2.0" to WebLogic10.3.3.0
including "EclipsLink2.0.2."

With WebLogic 10.3.2.0, 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
JpaHelper.getEntityManager".
   I used this code following.
     --> ServerSession serverSession =
JpaHelper.getEntityManager(em).getServerSession();

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

 Thanks
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Back to the top