Warning logged by liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:369) when classpath contains wildcards

Since upgrading to liquibase 4.5.0 we get a nasty warning/stack trace at startup.

The reason appears to be that we have a ‘*’ wildcard in our classpath - as we want to load any plugin jar the customer places in the plugins directory (and this is a valid syntax for java).

We do not want unnecessary WARNings logs in our application log as we have a strict definition that ‘a properly application runs without WARN or ERROR in the log’ !

I expect liquibase to either ignore wildcard entries or (better) liquibase to interpret the class path properly - in the same way the jvm / java runtime does; i.e. expanding wildcards.

2021-12-27_16:52:36.075- WARN-[main                                    ]-Cannot create filesystem for url file:/C:/Users/user1/Documents/mch_home/app-2.4.2.0.0-7235/plugins/*: Illegal char <*> at index 62: 
C:/Users/user1/Documents/app_home/app-2.4.2.0.0-7235/plugins/* {liquibase.resource.ClassLoaderResourceAccessor:141}
java.nio.file.InvalidPathException: Illegal char <*> at index 62: C:/Users/user1/Documents/app_home/app-2.4.2.0.0-7235/plugins/*
	at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
	at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
	at sun.nio.fs.WindowsUriSupport.fromUri(WindowsUriSupport.java:166)
	at sun.nio.fs.WindowsFileSystemProvider.getPath(WindowsFileSystemProvider.java:92)
	at java.nio.file.Paths.get(Paths.java:138)
	at liquibase.resource.ClassLoaderResourceAccessor.loadRootPaths(ClassLoaderResourceAccessor.java:67)
	at liquibase.resource.ClassLoaderResourceAccessor.init(ClassLoaderResourceAccessor.java:51)
	at liquibase.resource.ClassLoaderResourceAccessor.openStreams(ClassLoaderResourceAccessor.java:108)
	at liquibase.resource.AbstractResourceAccessor.openStream(AbstractResourceAccessor.java:18)
	at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:50)
	at liquibase.parser.core.xml.AbstractChangeLogParser.parse(AbstractChangeLogParser.java:15)
	at liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:369)
	at liquibase.Liquibase.lambda$update$1(Liquibase.java:224)
	at liquibase.Scope.lambda$child$0(Scope.java:177)
	at liquibase.Scope.child(Scope.java:186)
	at liquibase.Scope.child(Scope.java:176)
	at liquibase.Scope.child(Scope.java:155)
	at liquibase.Liquibase.runInScope(Liquibase.java:2404)
	at liquibase.Liquibase.update(Liquibase.java:211)
	at liquibase.Liquibase.update(Liquibase.java:197)
	at liquibase.Liquibase.update(Liquibase.java:193)
	at com.acme.tools.integration.persistence.liquibase.LiquibaseExecutor.execute(LiquibaseExecutor.java:228)
	at com.acme.tools.integration.persistence.liquibase.LiquibaseExecutor.update(LiquibaseExecutor.java:100)
	at com.acme.tools.integration.persistence.SchemaManager.updateSchema(SchemaManager.java:202)

[consultantleon]

Any expectation when this will be fixed?

[consultantleon]

The workaround is to configure a logger configuration and suppress the specific liquibase stack trace so not to worry our users. As in our case we know we don’t need the ‘’ path included for liquibase purpose it just goes well. But really there need to be a real solution so that classpath entries with '’ are properly included in your logic and so that logs do not need to be suppressed. It’s a clear regression in my view.