CompositeResourceAccessor list method invokes all ResourceAccessor list methods - fails in some conditions

General Discussion
1

Liquibase 3.3.2. (Though the current master code in the affected area is still the same)

I'm trying to set up a unit test framework where I'm running our Liquibase change sets in order to set up an in-memory (HSQL) database. It's pretty much working - except for the 'includeall'.

The underlying exception is:

Caused by: liquibase.exception.UnexpectedLiquibaseException: Cannot find base path 'master.xml' at liquibase.resource.AbstractResourceAccessor.convertToPath(AbstractResourceAccessor.java:126) at liquibase.resource.ClassLoaderResourceAccessor.list(ClassLoaderResourceAccessor.java:53) at liquibase.resource.CompositeResourceAccessor.list(CompositeResourceAccessor.java:40) at liquibase.changelog.DatabaseChangeLog.includeAll(DatabaseChangeLog.java:332)

So - here's the setup.

src |-main |-resources |-liquibase master.xml test |-java packages and unit tests

I'm using Spring's embedded-database to set up HSQL

I'm using a Java method for populating the HSQL db.

The base databaseChangeLog is master.xml, found in src\main\resources\liquibase. I'm trying to set things up so that I can just reference those using a file system resource accessor, but there are also references to elements that need the ClassLoaderResourceAccessor. So, I set up the Liquibase instance with a CompositeResourceAccessor - the first accessor in the list is a FileSystemResourceAccessor where I set the base in the constructor to be the path to where master.xml is found. The second is a ClassLoaderResourceAccessor.

Things are being found and parsed - until an includeall is found. This invokes the 'list' method on the CompositeResourceAccessor, which calls the list method on ALL the resourceAccessors that are defined. So, the first call to FileSystemResourceAccessor.list uses 'master.xml' as the relativeTo parameter, and returns a non-null set of paths. Then, a call is made to the ClassLoaderResourceAccessor, again using 'master.xml' as the relativeTo parameter - and that fails with the exception noted above, since master.xml can't be found in any of the class loader accessible places.

Here's the main code that sets things up:

catch (Exception e) {

e.printStackTrace();


}

}

Any ideas on this? Is this a potential bug in the CompositeResourceAccessor code? e.g. have it catch any exceptions and basically just eat them?) Or, could a parameter be added to that which controls how the list works? (i.e. stop iterating through the resourceAccessors as soon as a result comes back)?

I know I could implement my own CompositeResourceAccessor and override the list handling, but that seems kludgy to me…

Thanks!

Bob