Eclipselink is living in the past, DDL not reflecting Entities

Weird stuff… I have happily used EclipseLink / JPA 2 as provider for my persistence unit for a while (with a MySQL RDBMS in the back). I had DDL-drop/create turned off, since I wanted to keep records in the DB and there weren’t any changes to the Entities anyway.

Now I’ve just made some bigger changes to one Entity (adding some attributes, renaming / re-typing others, importing a previously embedded object flat into this entity, etc). I turn on DDL-drop/create, re-deploy a couple of times, and … nothing changes!

EclipseLink actually creates (and re-creates) the SQL Tables based on the old information! It’s like it has a copy of the Java class somewhere and ignores the one I just updated…

Even more crazy, the previously embedded object is gone. I deleted the class-file. Eclipselink still creates the attributes in the table of the previously embedding class.

I see no Exceptions in GlassFish server.log. I dropped and recreated the persistence Unit, no change. Any ideas? (Let me know if I should post any code / log entries, and I’ll update this post.)

Update: After setting eclipselink.logging.level to FINEST, I still see no exceptions. The DDL-script is created (with wrong columns in it) and happily executed on the DB (creating the wrong columns of course). In the logs I see EclipseLink talking about the fields that aren’t there anymore:

The alias name for the entity class [class mvs.entity.Shopper] is being defaulted to: Shopper.|#]

The column name for element [field msisdn] is being defaulted to: MSISDN.|#]

The column name for element [field imei] is being defaulted to: IMEI.|#]

In this case mvs.entity.Shopper is the class. msisdn is an existing field, but imei does not exist anymore. No idea where EclipseLink is getting the info from…

Btw, I have eclipselink.weaving set to false, since it was causing issues with lazy-loading. Could this be related?

Update 2: Following Gordon’s advice I have looked for old copies of the entity, but couldn’t find any. Deploying the appliation on a fresh GlassFish did not show the behaviour from above; instead the mapping was done correctly as was DDL-creation! Yippie 🙂

My only conclusion is that the old copy must be kept somewhere in GlassFish, even after undeploying… Does that make sense?


Installing a fresh copy of GlassFish and deploying the applications to it solved the problem. After comparing the two copies of GF, I found an old build artifact in glassfish/domains/domain1/lib, which contained old entity definitions. After removing that, everything was as expected.

So at the end of the day, my own stupid mistake.

Leave a Reply

Your email address will not be published. Required fields are marked *