Laird Nelson wrote:
> 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?
Deployment is calling a cleanup callback so everything should be cleaned
up on a failed deploy, but we do encounter bugs sometimes ;)
-marina
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>