Error Reading Migration File: null

General Discussion
1

I’m trying to launch Liquibase programatically and I’m running into some trouble.  Using 2.0 RC7, I’m trying to use the following code to launch Liquibase and run a group of changes.  Has anyone seen seen a similar issue, and if so, how did you work around it?

For reference, LIQUIBASE_SCRIPT_LOCATION = “conf/Database2.xml”

    Liquibase liquibase = new Liquibase(LIQUIBASE_SCRIPT_LOCATION, new FileSystemResourceAccessor(), new JdbcConnection(conn));

    String contexts = “audit,core,jbpm”;
    String tag = Long.toString(new Date().getTime());
    try {
    if(hasLiquibase) {
    System.out.println(“Tagging changeset”);
    liquibase.tag(tag);
    }
    liquibase.update(contexts);
    } catch(Exception e) {
    if(hasLiquibase) {
    liquibase.rollback(tag, contexts);
    }
    throw e;
    }

This is the stack trace that I receive:

liquibase.exception.ChangeLogParseException: Error Reading Migration File: null
        at liquibase.parser.core.xml.XMLChangeLogSAXParser.parse(XMLChangeLogSAXParser.java:91)
        at liquibase.Liquibase.update(Liquibase.java:105)

2

some kind of classloader path issue?

3

I lean toward no, since this is only a small java app that doesn’t use anything other than Java’s default classloader.

4

Apparently the behavior of XML entities has changed in Liquibase 2.0.  I had to change the location in the !ENTITY element from relative to the working directory to relative to the xml file.

Is this documented and I missed it?

5

I don’t know of what would have affected that off hand, but using ENTITY elements is not something I had looked at a lot. 

How are you using them?

Nathan

6

When we first started using liquibase, we kept everything in one file.  Eventually we split every thing out into separate files for new releases.  Due to some issues with the filename in the database change log table, the original changes had to maintain the first file name.

To do that we used a !ENTITY tag that pointed to the original changesets and imported them using an entity reference (ie:  &referenceName).  However, the default java resolver uses the pwd for relative paths, so we had to include an additional folder in the path compared to the files that we included using the tag.

Let me know if you need me to explain more or try to work up a small example.

7

I think I see what the issues were.  It is generally best to use the tag, there is a logicalPath attribute available on the root databaseChangeLog tag that allows you to override what liquibase considers to be the “file name” for the changesets in the changelog.  That will allow you to move your changesets to other files, or move changelog files around while keeping backwards compatibility.

Nathan

8

It’s definitely better to use the include tag, and we use it for everything other than this one legacy file.  You may want to note the change in the liquibase 2.0 upgrade guide.

9

I’ll do that.  Were you able to get a work-around for 2.0?

Nathan

10

I was able to work around it by changing the path from relative to the working directory to relative to the root XML changelog file.