Community
Participate
Working Groups
>Problem: Any unexpected exception like a CCE or spec defined IAE should not stop deployment of the persitence unit >Fix is to wrap the this.getMetamodel(); call in line 302 of the following with a try/catch/warning block to ensure that any exception during metamodel processing does not hold up the entityManager predeploy. >Design History: 46,92 eclipselink.orm-inbox@eclipse.org http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_46:_20090715:_Metamodel_initialization_on_EntityManagerFactory_creation http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_92:_20091008:_Move_metamodel_instance_field_from_EntityManagerFactory_to_EntityManagerSetupImpl
The small try/catch/warn/continue fix for this bug will be done by another JPA developer
Fix checked in to 2.0.1 and trunk. The fix catches an exception during the deploy init of the metamodel and logs a message at finest. Note, an actual call by the user to getMetamodel will still through an exception if the metal model init fails.
Created attachment 159457 [details] Medamodel Metamodel log text change as a result of verification an the Glassfish container >Test results on the Glassfish V2.1.1 container with a forced NPE in MetamodelImpl.initialize() to verify that any exception does not stop EM deploy() Daemon Thread [httpSSLWorkerThread-8080-0] (Suspended (breakpoint at line 391 in EntityManagerSetupImpl)) EntityManagerSetupImpl.deploy(ClassLoader, Map) line: 391 EntityManagerFactoryImpl.getServerSession() line: 153 EntityManagerFactoryImpl.createEntityManagerImpl(Map) line: 210 EntityManagerFactoryImpl.createEntityManager() line: 198 this EntityManagerSetupImpl (id=154) realClassLoader WebappClassLoader (id=156) additionalProperties HashMap<K,V> (id=163) deployProperties HashMap<K,V> (id=188) e NullPointerException (id=271) backtrace (id=279) cause null detailMessage null noBackTrace 0 stackTrace null stackTraceHolder null >Stack trace shows the exception log and the normal functioning of the persistence unit after a sucessfull deploy on an EE container [#|2010-02-18T10:54:21.770-0500|INFO|sun-appserver2.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=Main Thread;Sun GlassFish Enterprise Server v2.1.1;|WEB0302: Starting Sun GlassFish Enterprise Server v2.1.1|#] [#|2010-02-18T11:32:08.265-0500|INFO|sun-appserver2.1|org.eclipse.persistence.session.file:/C:/opt/glassfish/domains/domain1/applications/j2ee-apps/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseEAR/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseWeb_war/WEB-INF/classes/_enterprise|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;|file:/C:/opt/glassfish/domains/domain1/applications/j2ee-apps/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseEAR/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseWeb_war/WEB-INF/classes/_enterprise login successful|#] >Exception is logged, ignored and deploy() continues OK >[#|2010-02-18T11:34:50.209-0500|FINEST|sun-appserver2.1|org.eclipse.persistence.session.file:/C:/opt/glassfish/domains/domain1/applications/j2ee-apps/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseEAR/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseWeb_war/WEB-INF/classes/_enterprise.jpa_metamodel|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;ClassName=null;MethodName=null;_RequestID=ae1cab38-c772-4018-92ec-28166a69681e;|Initialization of the medamodel failed during deployment. Ignoring exception: [null] |#] [#|2010-02-18T11:35:26.292-0500|FINEST|sun-appserver2.1|org.eclipse.persistence.session.file:/C:/opt/glassfish/domains/domain1/applications/j2ee-apps/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseEAR/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseWeb_war/WEB-INF/classes/_enterprise.properties|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;ClassName=null;MethodName=null;_RequestID=ae1cab38-c772-4018-92ec-28166a69681e;|End deploying Persistence Unit enterprise; session file:/C:/opt/glassfish/domains/domain1/applications/j2ee-apps/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseEAR/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseWeb_war/WEB-INF/classes/_enterprise; state Deployed; factoryCount 1|#] [#|2010-02-18T11:35:30.301-0500|FINEST|sun-appserver2.1|org.eclipse.persistence.session.file:/C:/opt/glassfish/domains/domain1/applications/j2ee-apps/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseEAR/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseWeb_war/WEB-INF/classes/_enterprise.query|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;ClassName=null;MethodName=null;_RequestID=ae1cab38-c772-4018-92ec-28166a69681e;|Execute query ReadAllQuery(name="references" referenceClass=Cell sql="SELECT t1.ID, t1.STATE, t1.TSEQ, t1.RIGHT_ID FROM EL_CELL_EL_CELL t0, EL_CELL t1 WHERE ((t0.peers_ID = ?) AND (t1.ID = t0.references_ID))")|#] [#|2010-02-18T11:35:31.003-0500|FINE|sun-appserver2.1|org.eclipse.persistence.session.file:/C:/opt/glassfish/domains/domain1/applications/j2ee-apps/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseEAR/org.eclipse.persistence.example.jpa.server.glassfishv2.EnterpriseWeb_war/WEB-INF/classes/_enterprise.sql|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-0;ClassName=null;MethodName=null;_RequestID=ae1cab38-c772-4018-92ec-28166a69681e;|SELECT t1.ID, t1.STATE, t1.TSEQ, t1.RIGHT_ID FROM EL_CELL_EL_CELL t0, EL_CELL t1 WHERE ((t0.peers_ID = ?) AND (t1.ID = t0.references_ID)) bind => [880]|#] >The medamodel metamodel log text was fixed for SVN rev # 6310 (trunk, 2.0.1, 2.0.2 only) http://fisheye2.atlassian.com/changelog/eclipselink/?cs=6622 Rev# 6312 (2.0) is OK http://fisheye2.atlassian.com/browse/eclipselink/branches/2.0/trunk/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/EntityManagerSetupImpl.java?r=6312 6310 (trunk) is modified http://fisheye2.atlassian.com/browse/eclipselink/trunk/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/localization/i18n/TraceLocalizationResource.java?r=6310#l318 A full fix will be posted to bug# 303063
>This fix requires additional NPE handlers for possible reflective calls that fail 6 levels above in the stacktrace during initialize() >This will only fix deployment calls not direct API calls to the metamodel >A full fix to bug# 303063 will solve the base issue for DI 50 >from http://forums.java.net/jive/message.jspa?messageID=399285#399285 java.lang.NullPointerException at java.lang.Class.searchMethods(Class.java:2646) at java.lang.Class.getDeclaredMethod(Class.java:1935) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getDeclaredMethod(PrivilegedAccessHelper.java:212) at org.eclipse.persistence.internal.jpa.metamodel.ManagedTypeImpl.getTypeClassFromAttributeOrMethodLevelAccessor(ManagedTypeImpl.java:1365) at org.eclipse.persistence.internal.jpa.metamodel.SingularAttributeImpl.<init>(SingularAttributeImpl.java:96) at org.eclipse.persistence.internal.jpa.metamodel.ManagedTypeImpl.initialize(ManagedTypeImpl.java:1295) at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.initialize(MetamodelImpl.java:399) at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.<init>(MetamodelImpl.java:101) at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.<init>(MetamodelImpl.java:120) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.getMetamodel(EntityManagerSetupImpl.java:1939) >raised status - as this stops deployment for all users
>see related Spring 3.0 JIRA SPR-6826 https://jira.springsource.org/browse/SPR-6826
>Fix Summary/Workaround Essentially this fix just makes validation default to true unless disabled - validation is off by default - login during emf predeploy is now on by default >workaround is to enable validation in persistence.xml The following property is named as though the persistence unit is "only" used for validation. In fact it validates the persistence unit by doing a deploy just after the predeploy - without waiting for client code to login - after that it behaves normally. This solves our issue where we may get a NPE on an unitialized descriptor's javaClass (was null) set on a Metamodel ManagedType <property name="eclipselink.validation-only" value="True"/>
Created attachment 178158 [details] Option 7 (in use): Do a getServerSession that does a deploy/login that calls initializeDescriptors only for early emf.getMetamodel() users - em.getMetamodel() users do not login
>See the fix for bug # 322585 in SVN rev# 8141 for 2.2 and 8142 for 2.1.2 https://fisheye2.atlassian.com/changelog/eclipselink/?cs=8141 We now do a preemptive DB login via getServerSession to force initializeDescriptors so that a MappedSuperclass javaClass is set on the descriptor when a client does an emf.getMetamodel() or emf.getCriteriaBuilder() before at least one EntityManager is created or logged in. If a NullPointerException occurs on early post-predeploy but pre-deploy access to the Metamodel via an EntityManagerFactory.getMetamodel() or emf.getCriteriaBuilder() call before an initial login to the DB - then reopen this bug. NPE in ManagedTypeImpl.getTypeClassFromAttributeOrMethodLevelAccessor NPE in MetamodelImpl.initialize
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
