Change Proposal for LiquibaseServletListener

There is a combination of three settings for the LiquibaseServletListener which determines whether or not Liquibase is run:

- system property liquibase.should.run
- context parameter liquibase.host.includes
- context parameter liquibase.host.excludes

We are running multiple Liquibase-aware web applications in a number of Tomcat containers on different machines. Some but not all applications share the same Tomcat container.

Our requirement is that Liquibase should not run automatically in production by default, but developers usually want Liquibase to run in their own workspace.

The only way to achieve this currently is to set -Dliquibase.should.run=false in production. System properties in a webserver can only be set at server level and not at application level. You cannot have different settings of the same property for different applications running on the same server.

Server names in context parameters are not a very flexible solution either. The web.xml deployment descriptor contains compile time information. Developers cannot know at compile time all names of all servers this application is ever going to run on.

At the moment, we’ve chosen the following solution:

1) To avoid setting any system properties on the Tomcat container, we include a web.xml context parameter liquibase.host.includes=dummy, which effectively disables Liquibase by default.

2) Unfortunately, in the current implementation logic, setting -Dliquibase.should.run=true (for developer environments) has no effect in combination with non-empty liquibase.host.includes. For this reason, we had to patch the LiquibaseServletListener to make liquibase.should.run override any host includes/excludes.

This patch is just 3 lines of code, and I’m happy to contribute it if anyone sees some value in it, but after thinking this issue over again, I’d say that JNDI entries would be the preferred solution:

a) liquibase.should.run can be set either as system property or as a JNDI entry java:comp/env/liquibase.should.run.
b) If both are set, the system property takes precedence.
c) liquibase.should.run (no matter if set as property or from JNDI) always takes precedence over liquibase.host.includes/excludes. (And I think these deserve to be deprecated…)

The whole point of the JNDI entries is that they are set at deployment time and not at compile time. E.g. with Tomcat, each application running in a given Tomcat instance has its own context.xml including JNDI environment entries where the deployer can set liquibase.should.run per application, independent of any compile time settings in web.xml.

What do you think?

Best regards,
Harald

I think that’s a good idea. I’d like to see it implemented. Thanks