|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
|
|
EclipseLink in Glassfish, roundupHi all,
ok, so I read some more documentation and gave another try to deploy my Application in Glassfish with EclipseLink. With M3, I still have the issue of LAZY collections beeing empty. (They behave normal in TL Essentials, they also return content with FetchType.EAGER set -- only if set to LAZY they return a size of 0, btw. without having been serialized.) From what I understand from the TL documentation, I shouldn't have to care for weaving in an Application Server, so probably I was wrong assuming I had to start the GlassFish VM with a -javaagent parameter. Is this correct? Is there anything I could do to find out if the LAZY thing is a Glassfish issue, an EclipseLink problem or some kind of overfitting to TL Essentials from my side? (Only standard JPA involved, but still...) With M4, the following Exception happens when deploying the Application: Internal Exception: java.lang.UnsupportedOperationException at org .eclipse .persistence .exceptions .EntityManagerSetupException .predeployFailed(EntityManagerSetupException.java:203) ... 45 more Caused by: java.lang.UnsupportedOperationException at java.util.Collections $UnmodifiableCollection.addAll(Collections.java:1028) at org .eclipse .persistence .internal .jpa .metadata .MetadataProcessor.initPersistenceUnitClasses(MetadataProcessor.java: 196) What might be going on here? rv _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
|
|
Re: EclipseLink in Glassfish, roundupThank you for reporting the exception we will look into it and get back
to you. As for the lazy loading, is it reproducible with a simple testcase or is your application quite large? --Gordon wintermute@... wrote: > Hi all, > > ok, so I read some more documentation and gave another try to deploy > my Application in Glassfish with EclipseLink. > > With M3, I still have the issue of LAZY collections beeing empty. > (They behave normal in TL Essentials, they also return content with > FetchType.EAGER set -- only if set to LAZY they return a size of 0, > btw. without having been serialized.) > > From what I understand from the TL documentation, I shouldn't have to > care for weaving in an Application Server, so probably I was wrong > assuming I had to start the GlassFish VM with a -javaagent parameter. > Is this correct? > > Is there anything I could do to find out if the LAZY thing is a > Glassfish issue, an EclipseLink problem or some kind of overfitting to > TL Essentials from my side? (Only standard JPA involved, but still...) > > > With M4, the following Exception happens when deploying the Application: > > Internal Exception: java.lang.UnsupportedOperationException > at > org > .eclipse > .persistence > .exceptions > .EntityManagerSetupException > .predeployFailed(EntityManagerSetupException.java:203) > ... 45 more > Caused by: java.lang.UnsupportedOperationException > at java.util.Collections > $UnmodifiableCollection.addAll(Collections.java:1028) > at > org > .eclipse > .persistence > .internal > .jpa > .metadata > .MetadataProcessor.initPersistenceUnitClasses(MetadataProcessor.java: > 196) > > What might be going on here? > > rv > _______________________________________________ > eclipselink-users mailing list > eclipselink-users@... > https://dev.eclipse.org/mailman/listinfo/eclipselink-users > eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
|
|
Re: EclipseLink in Glassfish, roundupThis is very odd; I cannot think what could be causing the issue. Do you get any errors during deployment? Try setting logging to finest and see if anything odd is occurring.
You should not be starting Glassfish with the agent; the weaving should occur from the EJB 3.0 container contract the same as it did with TopLink Essentials. However weaving is not required for lazy collections, so weaving should not have any effect. It could have something to do with the weaving of change tracking, so you could try turning weaving off in your persistence.xml and see if the issue still occurs. By the way, does the same application work with TopLink Essentials, or do you get issues as well? Could you include the full exception stack trace with the error from M4. I will try to run our JPA server tests in Glassfish to see if I get the same issue as you are seeing.
James Sutherland EclipseLink, TopLink Wiki: EclipseLink, TopLink Forums: TopLink, EclipseLink Book: Java Persistence |
|
|
Re: EclipseLink in Glassfish, roundup> Try setting logging to finest and see if > anything odd is occurring. Nothing particularily odd. I get CONFIG-level messages stating that "Class yatayata.DocumentList could not weaved for change tracking as not supported by its mappings.", even with "persistence.tools.weaving.changetracking" set to "false" in persistence.xml, but that's about the oddest thing to happen. (There is no such warning for DocumentListSorting, btw, which is one of the offending Entities -- that makes sense to me, as all relationships are LAZY there.) > It could have something to do with the > weaving of change tracking, so you could try turning weaving off in > your > persistence.xml and see if the issue still occurs. Setting "persistence.tools.weaving" to false seems to have no effect? At least the "registered to be processed by weaver" messages stay. Tests still fail. > By the way, does the same application work with TopLink Essentials, > or do > you get issues as well? No, the application runs perfectly well on Essentials. (It's a rather large application developed for and tested with Glassfish/Essentials). Before you look into this: I'd like to do some more research to check if really /all/ LAZY relationships show up empty or if there are dependencies. I have a vague feeling that the problem occurrs more frequently in transactions that have already done a lot of data modification. (I double-checked the scaffolding and it's ok, and, as said, all is well with EAGER or when deploying on Essentials, but perhaps Essentials is more forgiving and the code is indeed doing something it shouldn't be doing.) I'll update you when I know more. Thanks for the quick response -- the M4 stack trace is attached. I'll go fire up the debugger now and find out more about the LAZY thing... rv --- #|2008-02-07T16:42:13.505+0100|WARNING|sun-appserver9.1| javax.enterprise.system.core.classloading| _ThreadID = 21 ;_ThreadName =Thread-29;_RequestID=fe9b7e59-34f3-473c-9789-6104f3bc0b33;|Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build M4 - 20080206)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.UnsupportedOperationException javax.persistence.PersistenceException: Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build M4 - 20080206)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.UnsupportedOperationException at org .eclipse .persistence .internal .jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:806) at org .eclipse .persistence .jpa .PersistenceProvider .createContainerEntityManagerFactory(PersistenceProvider.java:155) at com .sun .enterprise .server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java: 149) at com .sun .enterprise .server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java: 84) at com .sun .enterprise .server.AbstractLoader.loadPersistenceUnits(AbstractLoader.java:898) at com .sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java: 184) at com .sun .enterprise .server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126) at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java: 244) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 336) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 210) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 645) at com .sun .enterprise .admin .event .AdminEventMulticaster .invokeApplicationDeployEventListener(AdminEventMulticaster.java:928) at com .sun .enterprise .admin .event .AdminEventMulticaster .handleApplicationDeployEvent(AdminEventMulticaster.java:912) at com .sun .enterprise .admin .event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java: 461) at com .sun .enterprise .admin .event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java: 176) at com .sun .enterprise .admin .server .core .DeploymentNotificationHelper .multicastEvent(DeploymentNotificationHelper.java:308) at com .sun .enterprise .deployment .phasing .DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226) at com .sun .enterprise .deployment .phasing .ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298) at com .sun .enterprise .deployment .phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132) at com .sun .enterprise .deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java: 108) at com .sun .enterprise .deployment .phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com .sun .enterprise .deployment.phasing.PEDeploymentService.start(PEDeploymentService.java: 591) at com .sun .enterprise .deployment.phasing.PEDeploymentService.start(PEDeploymentService.java: 635) at com .sun .enterprise .admin .mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at com .sun .enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java: 375) at com .sun .enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java: 358) at com .sun .enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java: 464) at com .sun .jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java: 213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com .sun .jmx .interceptor .DefaultMBeanServerInterceptor .invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java: 784) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java: 90) at $Proxy1.invoke(Unknown Source) at com .sun .enterprise .admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java: 304) at com .sun .enterprise .interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174) at com .sun .enterprise .deployment .client .DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145) at com .sun.enterprise.deployment.client.DeployAction.run(DeployAction.java: 537) at java.lang.Thread.run(Thread.java:613) Caused by: Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build M4 - 20080206)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.UnsupportedOperationException at org .eclipse .persistence .exceptions .EntityManagerSetupException .predeployFailed(EntityManagerSetupException.java:203) ... 45 more Caused by: java.lang.UnsupportedOperationException at java.util.Collections $UnmodifiableCollection.addAll(Collections.java:1028) at org .eclipse .persistence .internal .jpa .metadata .MetadataProcessor.initPersistenceUnitClasses(MetadataProcessor.java: 196) at org .eclipse .persistence .internal .jpa .metadata .MetadataProcessor.processEntityMappings(MetadataProcessor.java:285) at org .eclipse .persistence .internal .jpa .deployment .PersistenceUnitProcessor .processORMetadata(PersistenceUnitProcessor.java:258) at org .eclipse .persistence .internal .jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:763) ... 44 more |#] _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
|
|
Re: EclipseLink in Glassfish, rounduphttps://bugs.eclipse.org/bugs/show_bug.cgi?id=218228 --Gordon wintermute@... wrote:
_______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
|
|
Re: EclipseLink in Glassfish, roundupGordon,
> Not sure if you noticed the subsequent announcement... I noticed -- thanks! That was very quick. Unfortunately, M4 still throws Exceptions on deployment, NPE this time. The stack trace is attached. On the LAZY relationship issue: This is a hard one. I spent two days trying to isolate the problem, and didn't succeed. Here are some of my findings: - Not all LAZY relationships show up empty - I tracked down the problem in one case to a single line in my code: Just before accessing the list, I retrieve a sibling of the list (referenced by the same entity, otherwise unrelated) from the persistence context. If I /hold/ the reference, the list comes out empty. If I retrieve the entity without holding a pointer to the other entity, the list shows up OK. I couldn't believe this when I encountered it friday night, but it was reproducible monday morning... - Even more disturbing: The error occurs in a JUnit test where a transaction runs for a rather long time and covers the creation and removal of a lot of entities. If I create 100 entities before accessing the LAZY list, the problem is there, the test fails. If I create 10, the list is OK, all's well. The very same code -- the only difference is the number of entities involved. - Well then, I thought. Whatever this is, it must be some caching issue. So I set "eclipselink.cache.type.default" to "NONE" and tried again -- and got a StackOverflowError when em.find()ing one of the entities. Scary. I switched back to Essentials and disabled caching for control -- and there it was, the same stack overflow, with none of my classes involved: At least, both of them down consistently, Essentials and EclipseLink. Of course, I can't be sure I hit the same problem twice with and without the caching, but anyway: I think I should go after the StackOverflow before trying anything else. Is there any sort of mapping known to cause StackOverflow errors at runtime when caching is disabled? Thanks a lot & greetings from Berlin, rv --- [#|2008-02-11T15:08:37.507+0100|WARNING|sun-appserver9.1| javax.enterprise.system.core.classloading| _ThreadID=32;_ThreadName=Thread-104;_RequestID=601205a5- eae6-4e9b-9508-66ee33fe157e;|Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build SNAPSHOT - 20080207)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.NullPointerException javax.persistence.PersistenceException: Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build SNAPSHOT - 20080207)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.NullPointerException at org .eclipse .persistence .internal .jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:806) at org .eclipse .persistence .jpa .PersistenceProvider .createContainerEntityManagerFactory(PersistenceProvider.java:155) at com .sun .enterprise .server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java: 149) at com .sun .enterprise .server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java: 84) at com .sun .enterprise .server.AbstractLoader.loadPersistenceUnits(AbstractLoader.java:898) at com .sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java: 184) at com .sun .enterprise .server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126) at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java: 244) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 336) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 210) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 645) at com .sun .enterprise .admin .event .AdminEventMulticaster .invokeApplicationDeployEventListener(AdminEventMulticaster.java:928) at com .sun .enterprise .admin .event .AdminEventMulticaster .handleApplicationDeployEvent(AdminEventMulticaster.java:912) at com .sun .enterprise .admin .event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java: 461) at com .sun .enterprise .admin .event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java: 176) at com .sun .enterprise .admin .server .core .DeploymentNotificationHelper .multicastEvent(DeploymentNotificationHelper.java:308) at com .sun .enterprise .deployment .phasing .DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226) at com .sun .enterprise .deployment .phasing .ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298) at com .sun .enterprise .deployment .phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132) at com .sun .enterprise .deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java: 108) at com .sun .enterprise .deployment .phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com .sun .enterprise .deployment.phasing.PEDeploymentService.start(PEDeploymentService.java: 591) at com .sun .enterprise .deployment.phasing.PEDeploymentService.start(PEDeploymentService.java: 635) at com .sun .enterprise .admin .mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at com .sun .enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java: 375) at com .sun .enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java: 358) at com .sun .enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java: 464) at com .sun .jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java: 213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com .sun .jmx .interceptor .DefaultMBeanServerInterceptor .invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java: 784) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java: 90) at $Proxy1.invoke(Unknown Source) at com .sun .enterprise .admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java: 304) at com .sun .enterprise .interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174) at com .sun .enterprise .deployment .client .DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145) at com .sun.enterprise.deployment.client.DeployAction.run(DeployAction.java: 537) at java.lang.Thread.run(Thread.java:613) Caused by: Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build SNAPSHOT - 20080207)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.NullPointerException at org .eclipse .persistence .exceptions .EntityManagerSetupException .predeployFailed(EntityManagerSetupException.java:203) ... 45 more Caused by: java.lang.NullPointerException at org .eclipse .persistence .internal .jpa.metadata.accessors.OneToOneAccessor.process(OneToOneAccessor.java: 76) at org .eclipse .persistence .internal .jpa .metadata .accessors .RelationshipAccessor.processRelationship(RelationshipAccessor.java:315) at org .eclipse .persistence .internal .jpa .metadata .MetadataProject .processAccessorsWithRelationships(MetadataProject.java:559) at org .eclipse .persistence .internal.jpa.metadata.MetadataProject.process(MetadataProject.java:549) at org .eclipse .persistence .internal .jpa .metadata.MetadataProcessor.processAnnotations(MetadataProcessor.java: 247) at org .eclipse .persistence .internal .jpa .deployment .PersistenceUnitProcessor .processORMetadata(PersistenceUnitProcessor.java:263) at org .eclipse .persistence .internal .jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:763) ... 44 more |#] _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
|
|
RE: EclipseLink in Glassfish, roundupHello,
Thanks for sticking with it. There was a major JPA xml processing migration in this milestone. The problem you are seeing now is with defaults for OneToOne mappings. Although defaulting OneToOne mappings is not supported by the JPA specification EclipseLink can default them given enough information. It seems there is a problem with the annotation processing code that enables that defaulting. ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=218517 ) The StackOverFlow is not a problem with your model. A cache type of NONE should only be used when you have no references to the objects that have a cache type of NONE (a very special case) otherwise StackOverFlows can occur. A cache type of NONE is an special case configuration. If you wish to disable caching you can set toplink.cache.shared.(default|<class>) = false as a persistence unit property. And yes this is confusing we will be working to make cache settings more intuitive. If possible can you provide the code you are executing in the Lazy loading case? --Gordon -----Original Message----- From: eclipselink-users-bounces@... [mailto:eclipselink-users-bounces@...]On Behalf Of wintermute@... Sent: Monday, February 11, 2008 9:09 AM To: EclipseLink User Discussions Subject: Re: [eclipselink-users] EclipseLink in Glassfish, roundup Gordon, > Not sure if you noticed the subsequent announcement... I noticed -- thanks! That was very quick. Unfortunately, M4 still throws Exceptions on deployment, NPE this time. The stack trace is attached. On the LAZY relationship issue: This is a hard one. I spent two days trying to isolate the problem, and didn't succeed. Here are some of my findings: - Not all LAZY relationships show up empty - I tracked down the problem in one case to a single line in my code: Just before accessing the list, I retrieve a sibling of the list (referenced by the same entity, otherwise unrelated) from the persistence context. If I /hold/ the reference, the list comes out empty. If I retrieve the entity without holding a pointer to the other entity, the list shows up OK. I couldn't believe this when I encountered it friday night, but it was reproducible monday morning... - Even more disturbing: The error occurs in a JUnit test where a transaction runs for a rather long time and covers the creation and removal of a lot of entities. If I create 100 entities before accessing the LAZY list, the problem is there, the test fails. If I create 10, the list is OK, all's well. The very same code -- the only difference is the number of entities involved. - Well then, I thought. Whatever this is, it must be some caching issue. So I set "eclipselink.cache.type.default" to "NONE" and tried again -- and got a StackOverflowError when em.find()ing one of the entities. Scary. I switched back to Essentials and disabled caching for control -- and there it was, the same stack overflow, with none of my classes involved: At least, both of them down consistently, Essentials and EclipseLink. Of course, I can't be sure I hit the same problem twice with and without the caching, but anyway: I think I should go after the StackOverflow before trying anything else. Is there any sort of mapping known to cause StackOverflow errors at runtime when caching is disabled? Thanks a lot & greetings from Berlin, rv --- [#|2008-02-11T15:08:37.507+0100|WARNING|sun-appserver9.1| javax.enterprise.system.core.classloading| _ThreadID=32;_ThreadName=Thread-104;_RequestID=601205a5- eae6-4e9b-9508-66ee33fe157e;|Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build SNAPSHOT - 20080207)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.NullPointerException javax.persistence.PersistenceException: Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build SNAPSHOT - 20080207)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.NullPointerException at org .eclipse .persistence .internal .jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:806) at org .eclipse .persistence .jpa .PersistenceProvider .createContainerEntityManagerFactory(PersistenceProvider.java:155) at com .sun .enterprise .server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java: 149) at com .sun .enterprise .server.PersistenceUnitLoaderImpl.load(PersistenceUnitLoaderImpl.java: 84) at com .sun .enterprise .server.AbstractLoader.loadPersistenceUnits(AbstractLoader.java:898) at com .sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java: 184) at com .sun .enterprise .server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126) at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java: 244) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 336) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 210) at com .sun .enterprise .server.ApplicationManager.applicationDeployed(ApplicationManager.java: 645) at com .sun .enterprise .admin .event .AdminEventMulticaster .invokeApplicationDeployEventListener(AdminEventMulticaster.java:928) at com .sun .enterprise .admin .event .AdminEventMulticaster .handleApplicationDeployEvent(AdminEventMulticaster.java:912) at com .sun .enterprise .admin .event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java: 461) at com .sun .enterprise .admin .event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java: 176) at com .sun .enterprise .admin .server .core .DeploymentNotificationHelper .multicastEvent(DeploymentNotificationHelper.java:308) at com .sun .enterprise .deployment .phasing .DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226) at com .sun .enterprise .deployment .phasing .ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298) at com .sun .enterprise .deployment .phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132) at com .sun .enterprise .deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java: 108) at com .sun .enterprise .deployment .phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com .sun .enterprise .deployment.phasing.PEDeploymentService.start(PEDeploymentService.java: 591) at com .sun .enterprise .deployment.phasing.PEDeploymentService.start(PEDeploymentService.java: 635) at com .sun .enterprise .admin .mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at com .sun .enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java: 375) at com .sun .enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java: 358) at com .sun .enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java: 464) at com .sun .jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java: 213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com .sun .jmx .interceptor .DefaultMBeanServerInterceptor .invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java: 784) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java: 90) at $Proxy1.invoke(Unknown Source) at com .sun .enterprise .admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java: 304) at com .sun .enterprise .interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174) at com .sun .enterprise .deployment .client .DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145) at com .sun.enterprise.deployment.client.DeployAction.run(DeployAction.java: 537) at java.lang.Thread.run(Thread.java:613) Caused by: Exception [EclipseLink-28018] (Eclipse Persistence Services - 1.0 (Build SNAPSHOT - 20080207)): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Predeployment of PersistenceUnit [ormpersistence] failed. Internal Exception: java.lang.NullPointerException at org .eclipse .persistence .exceptions .EntityManagerSetupException .predeployFailed(EntityManagerSetupException.java:203) ... 45 more Caused by: java.lang.NullPointerException at org .eclipse .persistence .internal .jpa.metadata.accessors.OneToOneAccessor.process(OneToOneAccessor.java: 76) at org .eclipse .persistence .internal .jpa .metadata .accessors .RelationshipAccessor.processRelationship(RelationshipAccessor.java:315) at org .eclipse .persistence .internal .jpa .metadata .MetadataProject .processAccessorsWithRelationships(MetadataProject.java:559) at org .eclipse .persistence .internal.jpa.metadata.MetadataProject.process(MetadataProject.java:549) at org .eclipse .persistence .internal .jpa .metadata.MetadataProcessor.processAnnotations(MetadataProcessor.java: 247) at org .eclipse .persistence .internal .jpa .deployment .PersistenceUnitProcessor .processORMetadata(PersistenceUnitProcessor.java:263) at org .eclipse .persistence .internal .jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:763) ... 44 more |#] _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
| Free embeddable forum powered by Nabble | Forum Help |