Skip to main content

NullPointerException In EclipseLink During EAR Deployment

15 replies [Last post]
teknomad
Offline
Joined: 2010-02-08

1. Glassfish v2.1.1

EAR Deployment currently succeeds while using TopLink. However, I have a requirement to upgrade to EclipseLink.

2. Upgraded to EclipseLink 2.0.0, by placing the eclipseLink.jar in the glassfish lib directory

The only change in the EAR file itself, which succeeded in deploying previously, is to the persistence.xml properties as described by EclipseLink documentation. Deploying that EAR leads to the following NullPointerException. And I have not a clue since it does not get to my code at all, although I will take a look at the EclipseLink source code. And I am uncertain whether the post belongs here or in an EclipseLink forum:

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.(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.(MetamodelImpl.java:101)
at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.(MetamodelImpl.java:120)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.getMetamodel(EntityManagerSetupImpl.java:1939)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:385)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:151)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:207)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:195)
at com.sun.jdo.spi.persistence.support.ejb.ejbc.PersistenceProcessor.loadPersistenceUnitBundle(PersistenceProcessor.java:573)
at com.sun.jdo.spi.persistence.support.ejb.ejbc.PersistenceProcessor.createTablesInDB(PersistenceProcessor.java:421)
at com.sun.jdo.spi.persistence.support.ejb.ejbc.PersistenceProcessor.processAppBundle(PersistenceProcessor.java:287)
at com.sun.jdo.spi.persistence.support.ejb.ejbc.PersistenceProcessor.processApplication(PersistenceProcessor.java:189)
at com.sun.jdo.spi.persistence.support.ejb.ejbc.DeploymentEventListenerImpl.processApplication(DeploymentEventListenerImpl.java:211)
at com.sun.jdo.spi.persistence.support.ejb.ejbc.DeploymentEventListenerImpl.processEvent(DeploymentEventListenerImpl.java:172)
at com.sun.jdo.spi.persistence.support.ejb.ejbc.DeploymentEventListenerImpl.notifyDeploymentEvent(DeploymentEventListenerImpl.java:122)
at com.sun.enterprise.deployment.backend.DeploymentEventManager.notifyDeploymentEvent(DeploymentEventManager.java:79)
at com.sun.enterprise.deployment.backend.AppDeployer.postDeploy(AppDeployer.java:401)
at com.sun.enterprise.deployment.backend.AppDeployer.deploy(AppDeployer.java:260)
at com.sun.enterprise.deployment.backend.AppDeployer.doRequestFinish(AppDeployer.java:148)
at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:208)
at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:966)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:280)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:298)
at com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.deploy(ApplicationsConfigMBean.java:584)
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:597)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:390)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:373)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:477)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:170)
at com.sun.enterprise.deployment.autodeploy.AutoDeployer.invokeDeploymentService(AutoDeployer.java:583)
at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployJavaEEArchive(AutoDeployer.java:564)
at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:495)
at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:270)
at com.sun.enterprise.deployment.autodeploy.AutoDeployControllerImpl$AutoDeployTask.run(AutoDeployControllerImpl.java:374)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

Joe

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mitesh Meswani

> but the missing tables with no exception in sight might prove harder
That is the most interesting use case :).
> Do you know any circumstances under which the tables would fail to appear for a successful EAR deployment,
Are you getting something like "expected DDL file
createDDL.jdbc is not available" in server.log? Any other
exception/ WARNING message in server.log?
Is your database reachable when you are deploying?
> bearing in mind that when I use Hibernate as the provider (i.e. only changing the
tag in the persistence.xml), I do get tables?

EclipseLink is the default JPA provider for GlassFish. We have tighter
integration with it for better user experience at redeploy and hence its
the GlassFish code that executes the DDL generated by EclipseLink. Where
as for Hibernate, we let it go to database directly. Hope that clarifies
the difference.
[att1.html]

teknomad
Offline
Joined: 2010-02-08

The string "DDL" does not appear anywhere in the server.log.

I tend to work with no exceptions allowed at all. There is only one warning, which can't be removed because it leads (or in the past led) to another bug:
"Context initialization parameter 'facelets.LIBRARIES' is deprecated.....please use 'javax.faces.FACELETS_LIBRARIES' in the future"
As an aside, I haven't checked again since, but GlassFish had this hard-coded somewhere, so when I changed it as requested, the application broke. It works as it is now.

Moving on, the database is reachable based on the fact that the MQ tables are in the database. In addition, If I surgically open the ear file, and change just the
tag in the persistence.xml to Hibernate's provider, and change nothing else at all, including the GlassFish configuration, the EAR file deploys and tables are created.

I haven't had a chance to return to this issue due to other deadlines, but I'd bet good money if I start removing logical components out of the EAR file (carefully so what remains works), the tables will miraculously appear, because as I mentioned before it has happened before. From memory, that issue was caused when a class in a jar in the lib directory of the ear file had a superclass which was in a EJB jar (i.e. a dependency issue). The EAR claimed to deploy successfully, but there were no tables. I moved the erroneous class into the EJB jar, and tables appeared at that time. Now they are gone again, and as before no clues show up.

Those are the hints that I have right now.

Thanks

Joe

teknomad
Offline
Joined: 2010-02-08

I have to admit that I couldn't believe my eyes :-)

After upgrading from EclipseLink 2.0.0 to 2.0.1, not only had the deployment NullPointerException gone, but the bytea to oid conversion seems to have been fixed too, without me having to specify the tag on all those classes i.e. just like in default Hibernate case.

Although all I had to do was swap out the persistence provider for the test, I couldn't help myself but physically remove the Hibernate jars just to certain I wasn't being fooled somehow...and sure enough, it all works just fine.

Well, I have to take my hat off to the Team!

Joe

teknomad
Offline
Joined: 2010-02-08

Thanks for you reply.

This will take a little while, because the actual application is complex, and I'll have to remove most of the noise, leaving just the problem itself. The ORM override will be easier, but the missing tables with no exception in sight might prove harder

Do you know any circumstances under which the tables would fail to appear for a successful EAR deployment, bearing in mind that when I use Hibernate as the provider (i.e. only changing the
tag in the persistence.xml), I do get tables?

Thanks

Joe

mvatkina
Offline
Joined: 2005-04-04

Hibernate table creation is a completely different process, so it's not possible to compare one with the other...

Try setting EclipseLink log level to FINER - may be it will give some clues?

-marina

teknomad
Offline
Joined: 2010-02-08

I hadn't heard anything for so long, I thought there was no one out there. So, here are some updates which might help.

As mentioned earlier the deploy failed completely with a NullPointerException. However, I have revisited the test at various points, and there are two other symptoms worth mentioning:

1. EclipseLink appears to be ignoring the relationship between field annotations and their override settings in an ORM. I've seen it complain that field has no @Temporal annotation even though the class clearly has it defined. That field happens to also have an override entry in the ORM, but only for the name of the field, not the tag. If I add the tag to match the annotation, then EclipseLink is happy.....but then I've duplicated the information for no apparent reason. But to keep it happy, I have done so. NB: Hibernate works fine in this respect.

2. EclipseLink 2.1.0 (recently released and used with GlassFish v3.0.1) claims it has successfully deployed the ear file, but no EJB tables are generated in the database (NB: I do get tables when I use Hibernate). I have seen this behavior before in an earlier version of EclipseLink working with GlassFish v3. There are no exceptions in the log, just no tables generated. At that time, by trial and error, I figured out that there was a silent exception which prevented the tables from being created. I determined this by deduction i.e. simply removing various classes and jar files from the ear file, until the tables were created, but of course the application was useless that way :-) But without the exception, this is difficult to report. If this is known behavior under some other circumstance, then please let me know.

Thanks

Joe

Mitesh Meswani

On 7/19/2010 2:59 PM, glassfish@javadesktop.org wrote:
> I hadn't heard anything for so long, I thought there was no one out there. So, here are some updates which might help.
>
> As mentioned earlier the deploy failed completely with a NullPointerException. However, I have revisited the test at various points, and there are two other symptoms worth mentioning:
>
> 1. EclipseLink appears to be ignoring the relationship between field annotations and their override settings in an ORM. I've seen it complain that field has no @Temporal annotation even though the class clearly has it defined. That field happens to also have an override entry in the ORM, but only for the name of the field, not the tag. If I add the tag to match the annotation, then EclipseLink is happy.....but then I've duplicated the information for no apparent reason. But to keep it happy, I have done so. NB: Hibernate works fine in this respect.
>
> 2. EclipseLink 2.1.0 (recently released and used with GlassFish v3.0.1) claims it has successfully deployed the ear file, but no EJB tables are generated in the database (NB: I do get tables when I use Hibernate). I have seen this behavior before in an earlier version of EclipseLink working with GlassFish v3. There are no exceptions in the log, just no tables generated. At that time, by trial and error, I figured out that there was a silent exception which prevented the tables from being created. I determined this by deduction i.e. simply removing various classes and jar files from the ear file, until the tables were created, but of course the application was useless that way :-) But without the exception, this is difficult to report. If this is known behavior under some other circumstance, then please let me know.
>
Can you please post an archive that reproduces the issue.

Thanks,
Mitesh
> Thanks
>
> Joe
> [Message sent by forum member 'teknomad']
>
> http://forums.java.net/jive/thread.jspa?messageID=478021
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

teknomad
Offline
Joined: 2010-02-08

Although the trace is slight different, this NullPointerException now exists in GlassFish v3, even using the latest EclipseLink jar? Any idea why that would be? It actually causes EAR deployment to fail altogether, just like in v2.1.1:

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.(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.(MetamodelImpl.java:101)
at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.(MetamodelImpl.java:120)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.getMetamodel(EntityManagerSetupImpl.java:1939)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:385)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:151)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:207)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:195)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.doJava2DB(PersistenceUnitLoader.java:273)
at org.glassfish.persistence.jpa.JPADeployer.load(JPADeployer.java:155)
at org.glassfish.persistence.jpa.JPADeployer.load(JPADeployer.java:55)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:310)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:141)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:573)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:459)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:391)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:376)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:195)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

obrienmi8
Offline
Joined: 2010-02-17

Teknomad,
I was just informed of your post - new NPE issue is under investigation as of 0940 EDT 20100719 - I will advise on progress and/or fix/rev #.
thank you
Michael O'Brien
www.eclipselink.org

obrienmi8
Offline
Joined: 2010-02-17

Hi,
Teknomad, thank you for raising this NPE. The following EclipseLink bug 303063 tracks progress on this issue forwarded to us by Mitesh, the fix and the SVN rev# and release/patch details will be posted there. If you have a chance can you post the @OneToOne or @Basic mapping that corresponds to the SingularAttribute that is causing the NPE as well as the containing @Entity or @MappedSuperclass to speed up reproducing this.

https://bugs.eclipse.org/303063

This issue is one with metamodel preprocessing during entityManager creation during predeploy and is not specific to an EE container (it can occur in an SE case as well - with the same object model)

thank you
/michael
http://www.eclipselink.org

teknomad
Offline
Joined: 2010-02-08

We have hundreds of classes in our ORM. To home in on this NullPointerException which provides no idea of the culprit, I tried guessing which of the entries it might be, and finally had to give up. I removed them all, and the problem went away, so I knew where we stood. I guess it would be instructive to wrap an exception handler around that area which mentions what is being processed in order to provide a clue next time around.

I have since wimped out on EclipseLink (temporarily) and installed Hibernate in GF, which works fine. It was not this NullPointerException which got me in the end, but even getting past this by temporarily accepting a configuration which did not depend on the ORM entries, the one thing I did need in the ORM, which is why I upgraded from TopLink, was to get past a problem related to bytea being used for with PostgreSQL, when we want OID columns in the database. EclipseLink promised might do the job. But I found that even using the EclipseLink namespace suggestions for as suggested by the docs, EclispeLink is not reading the the tag at all. My understanding is that I should be able to add that tag to an entity, and have bytea converted to ID before being passed to the database. But nothing. I even intenationally left off the required "name" attribute of the tag to be sure, and EclipseLink just ignored it. Without the ability to have OIDs stored for bytea, we can't use EclipseLink...Hibernate happens to do this automatically, and is doing now even in GlassFish.

However due to JPA configuration, it would not be difficult to swap back once the NullPOinterExceptions are sorted out, and in particular the tag works (assuming of course I didn't misconfigure something along the way :-). And no, I didn't try the @TypeConverter annotation to see if that works, because I don't want to use annotations in this case.

Thanks

Joe

obrienmi8
Offline
Joined: 2010-02-17

Teknomad,
Sorry to hear about these difficulties - I will forward on the note about the , our bytea/ID in PostgreSQL issue, I understand your object model is huge - I will provide a reproduction to test the bug with (I expect it to be one of Transformation, VariableOneToOne or a combination of mixed field/method accessor modes). A temporary handler for the NPE has been checked into the 2.0.2 stream yesterday - an unset descriptor.javaClass should not stop metamodel initialization now.
This issue that interferes with EM predeploy is critical and we will post a full fix as soon as we test it.
The fact that you mention you use orm.xml mapping info intead of JPA annotations is very usefull.
You may add your CC email to the following bug and/or vote for it, there may adjacent bugs entered for the other issues - I have increased it's priority

https://bugs.eclipse.org/bugs/show_bug.cgi?id=303063

thank you
/michael
http://www.eclipselink.org

obrienmi8
Offline
Joined: 2010-02-17

Teknomad,
Hi, we met about your issue this morning with management. I was referred to a fix put in for EclipseLink 2.0.1 that I forgot about - but I reviewed. It should solve your issue with metamodel initialization - in that any unforseen exceptions do not derail the EM deploy().

See the following fix that went into the 6312 build on 19 Jan 2010
http://fisheye2.atlassian.com/browse/eclipselink/branches/2.0/trunk/jpa/...

385 - this.getMetamodel();
385 + try {
386 + this.getMetamodel();
387 + } catch (Exception e) {
388 + session.log(SessionLog.FINEST, SessionLog.METAMODEL, "metamodel_init_failed", new Object[]{e.getMessage()});
389 + }

You may download the latest EclipseLink 2.0.1 jar and test the fix below.
http://www.eclipse.org/eclipselink/downloads/index.php

thank you
/michael
http://www.eclipselink.org

obrienmi8
Offline
Joined: 2010-02-17

Teknomad,
>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 (id=163)
deployProperties HashMap (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/...
6310 (trunk) is modified
http://fisheye2.atlassian.com/browse/eclipselink/trunk/foundation/org.ec...

A full fix will be posted to bug# 303063
thank you
/Michael O'Brien
http://www.eclipselink.org

teknomad
Offline
Joined: 2010-02-08

Thanks for your quick response. I followed the link to Eclipse 2.0.1 suggested earlier, licking my chops with anticipation, and willing to carry out a test by reverting my configuration, and alas, I click on the link and:

Eclipse downloads - file unavailable
The selected file is invalid, or it is no longer available for download.
This happens when the file is part of a nightly or development build. If so, please return to the project's home page and download a newer version.

I did that, and got the same result. I guess it will turn up, and then I'll let you know.

Joe