spring-boot-loader: URL stream handler regression

[DrVanScott]

Affected version: v1.4.2.RELEASE
Last working version: v1.4.1.RELEASE

I use org.springframework.boot.loader.PropertiesLauncher to start my program. Using v1.4.1 it was possible to configure log4j by specifying

-Dlog4j.configurationFile=classpath:./log4j2.xml

Using v1.4.2 this results in the following exception:

java.net.MalformedURLException: unknown protocol: classpath
	at java.net.URL.<init>(URL.java:593)
	at java.net.URL.<init>(URL.java:483)
	at java.net.URL.<init>(URL.java:432)
	at java.net.URI.toURL(URI.java:1089)
	at org.apache.logging.log4j.core.config.ConfigurationFactory.getInputFromUri(ConfigurationFactory.java:299)

The problem has been introduced by one of the following commits:

• d20ac56
• 6a68c8f

Please note that the above exception is also thrown in v1.4.1 if the specified configuration file cannot be found on the classpath. ("unknown protocol" instead of "file not found"...)

Here you can find details about the log4j "classpath" feature: https://issues.apache.org/jira/browse/LOG4J2-395

[wilkinsona]

Can you please provide a small sample that reproduces the problem?

[DrVanScott]

You can find a sample here: https://github.com/DrVanScott/spring-boot-loader-7581

After building you can run the example with

java -Dlog4j.configurationFile=classpath:./log4j2.xml -jar target/demo-0.0.1-SNAPSHOT-exec.jar

You can observe the following behaviour:

log4j.configurationFile	v1.4.1.RELEASE	v1.4.2.RELEASE
log4j2.xml	works	works
./log4j2.xml	works	error
classpath:log4j2.xml	works	works
classpath:./log4j2.xml	works	unkown protocol
invalid.xml	correct error message	correct error message
./invalid.xml	correct error message	correct error message
classpath:invalid.xml	unknown protocol	unknown protocol
classpath:./invalid.xml	unknown protocol	unknown protocol

[wilkinsona]

Thanks for the sample, I've reproduced the problem.

[wilkinsona]

While the behaviour has changed and something that worked previously does not, I think that's actually a good thing. Allow me to explain.

The change in behaviour was introduced in d20ac56. The intent of this commit was to align the behaviour of our URL stream handler for jar URLs with that of the JDK's. The JDK's URL stream handler rejects both ./log4j2.xml and classpath:./log4j2.xml as it doesn't do any normalisation of ./ (or ../ for that matter). Now our URL stream handler does too.

You can verify by using Maven's shade plugin to build your jar:

  <build>
    <plugins>
       <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>2.4.3</version>
        <configuration>
          <transformers>
            <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
              <mainClass>com.example.DemoApplication</mainClass>
            </transformer>
          </transformers>
        </configuration>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

This produces the following results:

log4j.configurationFile	Shaded
log4j2.xml	Works
./log4j2.xml	File not found in file system or classpath
classpath:log4j2.xml	Works
classpath:./log4j2.xml	Unknown protocol
invalid.xml	File not found in file system or classpath
./invalid.xml	File not found in file system or classpath
classpath:invalid.xml	Unknown protocol
classpath:./invalid.xml	Unknown protocol

As you can see, the two values that are successful are log4j2.xml and classpath:log4j2.xml. This is the same behaviour as you get with Spring Boot 1.4.2's handler.

[DrVanScott]

I totally agree. Thanks for clarification!