Hi,
We have a project built using the stripes framework and stripersist for
hibernate interaction.
Stripersist essentially works by scanning classes in your war at app
startup, finding ones tagged with the @Entity annotation, and then
dynamically configuring Hibernate. We had a project that had an entity in
it we'd decided to remove from the project. We removed the class, removed
the table from the db, and ensured there were no references to the class
hanging around in the project.
On our preview server, we did a full undeploy, followed by a new deploy, and
everyhing was fine. We then marked our war for prod and sent it to our
deployment team.
When it was deployed to prod, it was done as a redeploy - not an
undeploy/deploy. I had always assumed they were the same under the hood -
but maybe not?
What ended up happening was that the classfile we'd removed in the new
version got left on the filesystem, the new classes were unpacked around it,
and when the app started up, stripersist still found this old class file,
and tried to configure hibernate with it, which caused the whole thing to go
down in flames, as the db was missing that table.
Has anyone else ever noticed this problem? Or something like it...?
We're using 2.1
Thanks,
M@
--
"You can never run a hill too hard. You will give up long before you hurt
the hill..." -Anon