Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Bug 362564 - WebSphere specific randomisedorg.eclipse.persistence.exceptions.JPQLException error on startup
I am surprised that error message does not have any EclipseLink-specific-information in it. Is there any other error message? Do you see and EclipseLink logging in any of the logs? (if not, try eclipselink.logging.level=FINEST) 

Does turning off weaving help? (eclipselink.weaving=false)

-Tom

On 02/11/2011 10:39 AM, Nathan Drew wrote:

I think I tried this previously while researching the issue and this is the
results (from trying it just now); the EntityManager doesn’t get created or
injected - and everything else after that fails.

2011-11-02 14:34:53,332 ERROR
biz.wss.server.services.local.fx.pricing.fotinfo.FotInitialiser
[SIBJMSRAThreadPool : 1] (FotInitialiser.java:82) -
javax.ejb.EJBTransactionRolledbackException: nested exception is:
javax.ejb.EJBException: Injection failure; nested exception is:
java.lang.IllegalStateException: EntityManagerFactory has not been created for
PU : PuId=Bedrock-EAR#Bedrock.server.services.local.jar#WSSJPA

2011-11-02 14:34:52,573 ERROR
biz.wss.server.services.local.scheduler.TimerSchedulerInitialiser
[SIBJMSRAThreadPool : 4] (TimerSchedulerInitialiser.java:179) -
TimerSchedulerInitializer: initialization failed

javax.ejb.EJBTransactionRolledbackException: nested exception is:
javax.ejb.EJBException: Injection failure; nested exception is:
java.lang.IllegalStateException: EntityManagerFactory has not been created for
PU : PuId=Bedrock-EAR#Bedrock.server.services.local.jar#WSSJPA

*javax.ejb.EJBException: Injection failure; nested exception is:
java.lang.IllegalStateException: EntityManagerFactory has not been created for
PU : PuId=Bedrock-EAR#Bedrock.server.services.local.jar#WSSJPA*

*java.lang.IllegalStateException: EntityManagerFactory has not been created for
PU : PuId=Bedrock-EAR#Bedrock.server.services.local.jar#WSSJPA*

at
com.ibm.ws.jpa.management.JPAPUnitInfo.getEntityManagerFactory(JPAPUnitInfo.java:1369)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.ws.jpa.management.JPAPUnitInfo.getEntityManagerPool(JPAPUnitInfo.java:1577)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.ws.jpa.management.JPATxEntityManager.<init>(JPATxEntityManager.java:156)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.ws.jpa.management.JPAComponentImpl.getEntityManager(JPAComponentImpl.java:1053)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.ws.util.JPAJndiLookupObjectFactory.getObjectInstance(JPAJndiLookupObjectFactory.java:151)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.wsspi.injectionengine.InjectionBinding.getInjectionObject(InjectionBinding.java:659)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.wsspi.injectionengine.InjectionTargetField.inject(InjectionTargetField.java:245)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.ws.injectionengine.InjectionEngineImpl.inject(InjectionEngineImpl.java:620)
~[na:na]

at com.ibm.ejs.container.StatelessBeanO.initialize(StatelessBeanO.java:287)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.ejs.container.CMStatelessBeanOFactory.create(CMStatelessBeanOFactory.java:45)
~[com.ibm.ws.runtime.jar:na]

at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:1031)
~[com.ibm.ws.runtime.jar:na]

at com.ibm.ejs.container.EJSHome.createBeanO(EJSHome.java:1141)
~[com.ibm.ws.runtime.jar:na]

at
com.ibm.ejs.container.activator.UncachedActivationStrategy.atActivate(UncachedActivationStrategy.java:84)
~[com.ibm.ws.runtime.jar:na]

at com.ibm.ejs.container.activator.Activator.activateBean(Activator.java:599)
~[com.ibm.ws.runtime.jar:na]

at com.ibm.ejs.container.EJSContainer.preInvokeActivate(EJSContainer.java:3964)
[com.ibm.ws.runtime.jar:na]

at com.ibm.ejs.container.EJSContainer.EjbPreInvoke(EJSContainer.java:3349)
[com.ibm.ws.runtime.jar:na]

at
biz.wss.interfaces.services.scheduler.EJSLocal0SLTimerSchedulerEJB_299ec695.refresh(EJSLocal0SLTimerSchedulerEJB_299ec695.java)
~[na:DEV-r314855]

at
biz.wss.server.services.local.scheduler.TimerSchedulerInitialiser.start(TimerSchedulerInitialiser.java:123)
[Bedrock.server.services.local.jar:DEV-r314855]

at
biz.wss.server.services.local.scheduler.TimerSchedulerInitialiser.onMessage(TimerSchedulerInitialiser.java:94)
[Bedrock.server.services.local.jar:DEV-r314855]

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0]

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
~[na:1.6.0]

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
~[na:1.6.0]

at java.lang.reflect.Method.invoke(Method.java:611) ~[na:1.6.0]

at com.ibm.ejs.container.EJSContainer.invokeProceed(EJSContainer.java:5874)
[com.ibm.ws.runtime.jar:na]

at
com.ibm.ejs.container.interceptors.InvocationContextImpl.proceed(InvocationContextImpl.java:586)
[com.ibm.ws.runtime.jar:na]

at
biz.wss.server.services.logging.analysis.MethodTimerInterceptor.intercept(MethodTimerInterceptor.java:161)
[Bedrock.server.services.exception.jar:DEV-r314855]

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0]

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
~[na:1.6.0]

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
~[na:1.6.0]

at java.lang.reflect.Method.invoke(Method.java:611) ~[na:1.6.0]

at
com.ibm.ejs.container.interceptors.InterceptorProxy.invokeInterceptor(InterceptorProxy.java:227)
[com.ibm.ws.runtime.jar:na]

at
com.ibm.ejs.container.interceptors.InvocationContextImpl.proceed(InvocationContextImpl.java:566)
[com.ibm.ws.runtime.jar:na]

at
com.ibm.ejs.container.interceptors.InvocationContextImpl.doAroundInvoke(InvocationContextImpl.java:217)
[com.ibm.ws.runtime.jar:na]

at
com.ibm.ejs.container.MessageEndpointHandler.invokeMdbMethod(MessageEndpointHandler.java:1080)
[com.ibm.ws.runtime.jar:na]

at
com.ibm.ejs.container.MessageEndpointHandler.invoke(MessageEndpointHandler.java:778)
[com.ibm.ws.runtime.jar:na]

at $Proxy42.onMessage(Unknown Source) [na:na]

at
com.ibm.ws.sib.api.jmsra.impl.JmsJcaEndpointInvokerImpl.invokeEndpoint(JmsJcaEndpointInvokerImpl.java:233)
[com.ibm.ws.sib.server.jar:1.0.0]

at
com.ibm.ws.sib.ra.inbound.impl.SibRaDispatcher.dispatch(SibRaDispatcher.java:900) [com.ibm.ws.sib.server.jar:1.0.0]

at
com.ibm.ws.sib.ra.inbound.impl.SibRaSingleProcessListener$SibRaWork.run(SibRaSingleProcessListener.java:552)
[com.ibm.ws.sib.server.jar:1.0.0]

at com.ibm.ejs.j2c.work.WorkProxy.run(WorkProxy.java:399)
[com.ibm.ws.runtime.jar:na]

at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1604)
[com.ibm.ws.runtime.jar:na]

Kind Regards

Nathan

*From:*eclipselink-users-bounces@xxxxxxxxxxx
[mailto:eclipselink-users-bounces@xxxxxxxxxxx] *On Behalf Of *Tim Martin
*Sent:* 02 November 2011 14:21
*To:* EclipseLink User Discussions
*Subject:* Re: [eclipselink-users] Bug 362564 - WebSphere specific
randomisedorg.eclipse.persistence.exceptions.JPQLException error on startup

Nathan will be trying it shortly...

it's all container managed - injected with


@PersistenceContext(unitName = "WSSJPA")
protected EntityManager em;

On 02/11/2011 14:15, Tom Ware wrote:

What about the other questions below? What about the
eclipselink.deploy-on-startup property?

On 02/11/2011 10:01 AM, Tim Martin wrote:

we have a servlet context listener that sends out some msgs on a few jms queues
which are received by some mdb's to initialise caches and bits of static data,
the mdbs can and sometimes do run concurrently....

On 02/11/2011 13:13, Tom Ware wrote:

How is your startup multi-threaded?

Is you EntityManager container managed or application managed? Is it
injected, or do you obtain it some other way?

One thing you could try is to set the following persistence unit property:

eclipselink.deploy-on-startup=true

That property should ensure that all the initialization happens as soon as the
first entity manager factory is instantiated.

-Tom

On 02/11/2011 7:21 AM, Tim Martin wrote:

these errors all occur during application start up - ie when all the named
queries are validated/ compiled when the first named query is created,
we have several queries in different threads that would run during application
startup at about the same time

could it be some race condition where 2or more threads are trying dothe same
thing that should only happen once ???

eg in the stack trace below it goes into /thru some websphere specific code to
get the entity manager / create named query ?

[11/1/11 12:16:36:933 UTC] 00000026 SystemOut O [EL Severe]: 2011-11-01
12:16:36.913--ServerSession(217124081)--Local Exception Stack: Exception
[EclipseLink-8030] (Eclipse Persistence Services - 2.2.1.v20110721-r9766):
org.eclipse.persistence.exceptions.JPQLException Exception Description: Error
compiling the query [DataElementGroupAudit.checkPrevAuditsByNaturalKey: SELECT
NEW
biz.wss.interfaces.entities.foureyes.auditmaker.AuditStateUser(a.auditFields.currentState,


a.auditFields.auditUser) FROM DataElementGroupAudit a WHERE a.code = :code ORDER
BY a.auditFields.auditDateTime DESC], line 1, column 76: unknown state or
association field [auditFields] of class
[biz.wss.interfaces.entities.bo.dataelement.group.foureyes.DataElementGroupAudit].

at
org.eclipse.persistence.exceptions.JPQLException.unknownAttribute(JPQLException.java:457)



at org.eclipse.persistence.internal.jpa.parsing.DotNode.validate(DotNode.java:88)
at org.eclipse.persistence.internal.jpa.parsing.DotNode.validate(DotNode.java:73)
at
org.eclipse.persistence.internal.jpa.parsing.ConstructorNode.validate(ConstructorNode.java:73)


at
org.eclipse.persistence.internal.jpa.parsing.SelectNode.validate(SelectNode.java:293)


at
org.eclipse.persistence.internal.jpa.parsing.ParseTree.validate(ParseTree.java:201)

at
org.eclipse.persistence.internal.jpa.parsing.ParseTree.validate(ParseTree.java:183)

at
org.eclipse.persistence.internal.jpa.parsing.ParseTree.validate(ParseTree.java:173)

at
org.eclipse.persistence.internal.jpa.parsing.JPQLParseTree.populateReadQueryInternal(JPQLParseTree.java:110)


at
org.eclipse.persistence.internal.jpa.parsing.JPQLParseTree.populateQuery(JPQLParseTree.java:84)



at
org.eclipse.persistence.internal.jpa.EJBQueryImpl.buildEJBQLDatabaseQuery(EJBQueryImpl.java:216)


at
org.eclipse.persistence.internal.jpa.JPAQuery.processJPQLQuery(JPAQuery.java:106)
at org.eclipse.persistence.internal.jpa.JPAQuery.prepare(JPAQuery.java:90)
at
org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:579)

at
org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:539)

at
org.eclipse.persistence.internal.sessions.AbstractSession.processJPAQueries(AbstractSession.java:2173)



at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:414)



at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:680)



at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:628)



at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:233)


at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:394)



at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:185)



at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:242)



at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:237)


_/*at com.ibm.ws.jpa.management.JPAEMPool.getEntityManager(JPAEMPool.java:140)
at
com.ibm.ws.jpa.management.JPATxEntityManager.getEMInvocationInfo(JPATxEntityManager.java:235)



at
com.ibm.ws.jpa.management.JPAEntityManager.createNamedQuery(JPAEntityManager.java:302)


*/_
at biz.wss.jpa.DbType.createNamedQuery(DbType.java:62)

On 02/11/2011 11:05, Nathan Drew wrote:


Hi Tom,

Glad to know it's not something glaringly obvious we're missing (at least for
now anyway!) - it is indeed a confusing issue since it works on two out of the
three JEE server platforms we develop for without issue.

In answer to your questions:

·Is the packaging the same on all the different servers you are running on?

oIt should be, yes, our ANT scripts only do JEE platform specific things such
as use specific libraries and perhaps include specific WAR files according to
the type

·How is your persistence unit packaged and deployed?

oWe have a single persistence.xml configured inside one of our Jar files.

oThe mapping file is stored within the same JAR

·Are all the classes in the same jar?

oNo, the persistence.xml references 4 <jar-files>

·Are the classes dependent on classes from other jars?

oThe ones that it is complaining about exist within one of the specified
<jar-files> and don't

·Is there a chance that some of the dependencies are not properly loaded?

oI think TopLink Essentials would have had a similar problem if this was the
case.

·Is there anything in common between queries that do not seem to work?

oOne thing I do notice about the queries it complains about is that they all
seem to be of the type "SELECT NEW … FROM …" not sure how relevant that is.

·(inherited fields?)

oThe entity classes that are complained about do extend other classes that are
defined as @MappedSuperclass, which in turn extend an abstract class (and
those aren't annotated as @MappedSuperclass)

oIt always seems to reference @Embedded fields

·Is there a chance that queries of the same name are defined in multiple
places?

oI don't believe so - we've recently added a JUnit test to check for this,
plus I manually checked via grep and an Excel spread sheet.

I'm not sure if that answers all of your questions, specifically about the
packaging so please let me know if you need more detail.

We were operating TopLink Essentials without any problems with WebSphere -
which is why we think it might be a bug within EclipseLink somehow.

Kind Regards

Nathan

-----Original Message-----
From: eclipselink-users-bounces@xxxxxxxxxxx
<mailto:eclipselink-users-bounces@xxxxxxxxxxx>
[mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of Tom Ware
Sent: 01 November 2011 17:35
To: eclipselink-users@xxxxxxxxxxx <mailto:eclipselink-users@xxxxxxxxxxx>
Subject: Re: [eclipselink-users] Bug 362564 - WebSphere specific
randomisedorg.eclipse.persistence.exceptions.JPQLException error on startup

I have to admit that I am as confused about this issue as you appear to be.

The only theory I can come up with is that there is some issue with all the
queries and that the error is different for different deployments because they
are instantiated parsed into the EclipseLink metadata in a random order.

Since deployment is working on other application servers, this leads me to
believe that this is somehow a packaging issue.

Is the packaging the same on all the different servers you are running on?

How is your persistence unit packaged and deployed?

Are all the classes in the same jar?

Are the classes dependent on classes from other jars?

Is there a chance that some of the dependencies are not properly loaded?

Is there anything in common between queries that do not seem to work?

(inherited fields?)

Is there a chance that queries of the same name are defined in multiple places?

-Tom

On 01/11/2011 10:54 AM, Nathan Drew wrote:

 > Hi Tom,

 >

 > I've retried with another example stack trace added to the ticket for

 > eclipselink version 2.3.1-RC1 (2.3.1.v20111018-r10243)

 >

 > Kind Regards

 > Nathan

 >

 >

 > -----Original Message-----

 > From: eclipselink-users-bounces@xxxxxxxxxxx
<mailto:eclipselink-users-bounces@xxxxxxxxxxx>

 > [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of Nathan

 > Drew

 > Sent: 01 November 2011 13:49

 > To: EclipseLink User Discussions

 > Subject: Re: [eclipselink-users] Bug 362564 - WebSphere specific

 > randomisedorg.eclipse.persistence.exceptions.JPQLException error on

 > startup

 >

 > Will do - just noticed in the trace that it had the old 2.2.1 library

 > running, will retry and update the ticket and let you know.

 >

 > Kind Regards

 > Nathan

 >

 > -----Original Message-----

 > From: eclipselink-users-bounces@xxxxxxxxxxx
<mailto:eclipselink-users-bounces@xxxxxxxxxxx>

 > [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of Tom Ware

 > Sent: 01 November 2011 13:21

 > To: eclipselink-users@xxxxxxxxxxx <mailto:eclipselink-users@xxxxxxxxxxx>

 > Subject: Re: [eclipselink-users] Bug 362564 - WebSphere specific

 > randomised org.eclipse.persistence.exceptions.JPQLException error on

 > startup

 >

 > Can you try the latest 2.3.1 milestone (RC1)?

 >

 > http://www.eclipse.org/eclipselink/downloads/milestones.php

 >

 > -Tom

 >

 > On 01/11/2011 9:07 AM, Nathan Drew wrote:

 >> Hi,

 >>

 >> Has anyone seen anything similar in WAS only? GlassFish and WebLogic

 >> both seem to run without ever hitting this "random" JPQL exception on

 >> startup - see

 >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=362564 for details.

 >>

 >> Many Thanks

 >>

 >> Nathan

 >>

 >>

 >>

 >> _______________________________________________

 >> eclipselink-users mailing list

 >> eclipselink-users@xxxxxxxxxxx <mailto:eclipselink-users@xxxxxxxxxxx>
<mailto:eclipselink-users@xxxxxxxxxxx>

 >> https://dev.eclipse.org/mailman/listinfo/eclipselink-users

 > _______________________________________________

 > eclipselink-users mailing list

 > eclipselink-users@xxxxxxxxxxx <mailto:eclipselink-users@xxxxxxxxxxx>
<mailto:eclipselink-users@xxxxxxxxxxx>

 > https://dev.eclipse.org/mailman/listinfo/eclipselink-users

 >

 >

 > _______________________________________________

 > eclipselink-users mailing list

 > eclipselink-users@xxxxxxxxxxx <mailto:eclipselink-users@xxxxxxxxxxx>
<mailto:eclipselink-users@xxxxxxxxxxx>

 > https://dev.eclipse.org/mailman/listinfo/eclipselink-users

 >

 >

 > _______________________________________________

 > eclipselink-users mailing list

 > eclipselink-users@xxxxxxxxxxx <mailto:eclipselink-users@xxxxxxxxxxx>
<mailto:eclipselink-users@xxxxxxxxxxx>

 > https://dev.eclipse.org/mailman/listinfo/eclipselink-users

_______________________________________________

eclipselink-users mailing list

eclipselink-users@xxxxxxxxxxx <mailto:eclipselink-users@xxxxxxxxxxx>
<mailto:eclipselink-users@xxxxxxxxxxx>

https://dev.eclipse.org/mailman/listinfo/eclipselink-users



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



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

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



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

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



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

Back to the top