I've played around off and on for...wow, years now :-| with Liquibase (
http://www.liquibase.org) and its support for running database updates at
ServletContext initialization time.
Head over to the website for more details, but in brief Liquibase manages
DDL commands against your database. It ships with an optional
ServletContextListener so that you can run these idempotent updates (well
they're idempotent if they've been run before :-)) every time your
application is deployed (every time the servlet context is initialized).
There are obviously pros and cons to this, but it's at any rate
interesting.
Sometimes your database update scripts are um shall we say syntax
challenged. I of course have never ever written such a syntax challenged
database upgrade scripts. Ahem.
Anyhow, at that point Liquibase fails, and the servlet context listener
fails, and some kind of RuntimeException is thrown--and the deployment
obviously is screwed up. Er, I mean, I have this friend to whom this sort
of thing happens. Sometimes.
But I've (he's) noticed that this leaves GlassFish in some kind of
indeterminate state. I'm writing this from memories of this occurring in
the past, but I seem to recall that the security/policy generation stuff
has partially completed at this point and isn't cleaned up or something of
that nature.
Is it supposed to be the case that if a deployment bombs out during
ServletContext initialization that GlassFish should be fully cleaned up
afterwards, or is this such a crazy thing in the lifecycle of the container
that there's not really an opportunity to clean up?
Best,
Laird
--
http://about.me/lairdnelson