Spring-boot: "Ignoring Class-Path entry ... as ... does not exists" checks wrong path?

[micheljung]

Possible duplicate of #9802

After upgrading Spring Boot, I get a ton of these messages:

Ignoring Class-Path entry file:/C:/Program%20Files/Java/jdk1.8.0_131/jre/lib/charsets.jar found in C:\Users\MyUser\AppData\Local\Temp\classpath113224.jar as C:\Users\MyUser\AppData\Local\Temp\file:\C:\Program%20Files\Java\jdk1.8.0_131\jre\lib\charsets.jar does not exist
Ignoring Class-Path entry file:/C:/Users/MyUser/.gradle/caches/modules-2/files-2.1/org.springframework.boot/spring-boot-actuator/1.5.6.RELEASE/2a0e4f39d58078159c2929c039e7c7813b325871/spring-boot-actuator-1.5.6.RELEASE.jar found in C:\Users\MyUser\AppData\Local\Temp\classpath113224.jar as C:\Users\MyUser\AppData\Local\Temp\file:\C:\Users\MyUser\.gradle\caches\modules-2\files-2.1\org.springframework.boot\spring-boot-actuator\1.5.6.RELEASE\2a0e4f39d58078159c2929c039e7c7813b325871\spring-boot-actuator-1.5.6.RELEASE.jar does not exist

Now if you look closely, you'll see that the "... does not exist" part lists an invalid path:

...\Temp\file:\C:\Users\MyUser\...

So either the checked file or the log output is definitely wrong :)

[snicoll]

After upgrading

Can you provide the version you were at and the new version?

[snicoll]

A simple Jersey app with Devtools outputs this (master)

Ignoring Class-Path entry $hk2-utils.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$hk2-utils.$jar does not exist
Ignoring Class-Path entry $javax.inject.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$javax.inject.$jar does not exist
Ignoring Class-Path entry $hk2-api.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$hk2-api.$jar does not exist
Ignoring Class-Path entry $aopalliance-repackaged.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$aopalliance-repackaged.$jar does not exist
Ignoring Class-Path entry $config-types.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$config-types.$jar does not exist
Ignoring Class-Path entry $hk2-core.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$hk2-core.$jar does not exist
Ignoring Class-Path entry $hk2-config.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$hk2-config.$jar does not exist
Ignoring Class-Path entry $tiger-types.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$tiger-types.$jar does not exist
Ignoring Class-Path entry $hibernate-validator.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$hibernate-validator.$jar does not exist
Ignoring Class-Path entry $validation-api.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$validation-api.$jar does not exist
Ignoring Class-Path entry $jboss-logging.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$jboss-logging.$jar does not exist
Ignoring Class-Path entry $classmate.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$classmate.$jar does not exist
Ignoring Class-Path entry $hk2-locator.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$hk2-locator.$jar does not exist
Ignoring Class-Path entry $javax.inject.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$javax.inject.$jar does not exist
Ignoring Class-Path entry $javassist.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$javassist.$jar does not exist
Ignoring Class-Path entry $hk2-runlevel.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$hk2-runlevel.$jar does not exist
Ignoring Class-Path entry $class-model.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$class-model.$jar does not exist
Ignoring Class-Path entry $asm-all-repackaged.$jar found in /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/hk2-2.5.0-b32.jar as /Users/snicoll/.m2/repository/org/glassfish/hk2/hk2/2.5.0-b32/$asm-all-repackaged.$jar does not exist

[micheljung]

My bad. I was at 1.4.4.RELEASE, this message got introduced in 1.4.6.RELEASE, I updated to 1.5.6.RELEASE.

I launched from my IDE and I'm using Gradle.

[wilkinsona]

Yuck. I propose that we do two things here:

1. Open a bug for the problematic entries in hk2's manifest
2. Change DevTools to log once per jar with a problematic Class-Path manifest attribute and list all of the problems in that one message

[micheljung]

I can't reproduce this anymore. Maybe some project rebuild fixed it? 1.5.6.RELEASE

[snicoll]

@micheljung that's fine. I found a case myself (see above).

[enazarchuk]

Hi, everyone,
I've tried to start using devtools, but it seems that I can't because of this issue.
I'm using IntelliJ Idea 2017.2.2 for Windows with classpath jar enabled. According to #5127, devtools should support that. The problem is that the jar's manifest contains absolute paths, but org.springframework.boot.devtools.restart.ChangeableUrls can't find them, because it uses
new File(jarFile.getName()).getParentFile() as a base directory, and treats the paths in the manifest as relative. As a result, it fails to find dependencies using paths like
C:\Users\{username}\AppData\Local\Temp\file:\C:\Users\{username}\.gradle\caches\modules-2\files-2.1\software.amazon.ion\ion-java\1.0.2\ee9dacea7726e495f8352b81c12c23834ffbc564\ion-java-1.0.2.jar

[wilkinsona]

@enazarchuk IMO, that's a bug in IDEA and, I believe, a change in behaviour from when #5127 was fixed. The documentation for the Class-Path manifest attribute states that:

The manifest for an application can specify one or more relative URLs referring to the JAR files and directories for other libraries that it requires. These relative URLs are treated relative to the code base from which the containing application was loaded.

If it works then I believe that IDEA is relying on non-standard behaviour and I don't really want to replicate that in Boot.

[enazarchuk]

@wilkinsona Thanks for the prompt reply. Created an issue https://youtrack.jetbrains.com/issue/IDEA-178585

[akozlova]

IDEA always uses absolute paths (you can download old classpath.jar from the related issue to ensue that), cause relative paths require "the base" and it's not that clear what base should be. I bet that the most manifests I saw assume that the jar with the manifest is the base (as far as I can see from comments above, spring dev now uses it as well) though from the documentation it's more likely the application working directory, no?

[moneydance]

Hi, I am also running into this issue. Is it solvable on my end, or do I have to wait for a fix? I'm using spring-boot 2.0.0.M3.

Best Ben

[wilkinsona]

@moneydance What do you mean by "this issue"? If you're referring to the wrong paths being checked then you should follow https://youtrack.jetbrains.com/issue/IDEA-178585. The wrong paths are being checked as, apparently, the IDEA-generated manifest is incorrect. If you're referring to the volume of logging produced by such a manifest then that has been fixed in https://github.com/spring-projects/spring-boot/commit/8761ef547c05084e539b8c035ffca6e9e72bd596 and will be part of today's 1.5.7 release.

[akozlova]

@wilkinsona Hi, are you sure that it's IDEA bug? The corresponding change in the devtools commit

       -   urls.add(new URL(base, entry));
       +  File referenced = new File(parent, entry);

[wilkinsona]

@akozlova I'm as sure as I can be. Please see my comment above.

[wilkinsona]

I bet that the most manifests I saw assume that the jar with the manifest is the base (as far as I can see from comments above, spring dev now uses it as well)

That's the assumption that I would expect them to make.

though from the documentation it's more likely the application working directory, no?

No, I don't think so. OpenJDK uses the code source URL as the base for the URLs that it creates from the entries in the manifest's Class-Path attribute. The code source URL is the URL for the jar file that contains the manifest.

[akozlova]

The first parameter of URL constructor is context, it's not used as "parent" in java.io.File.

[wilkinsona]

Right. I was trying to address your question about whether things should be relative to the working directory or to the jar file with the manifest. That code, I believe, shows that it's the latter.

I said above that I thought IDEA's behaviour had changed since I fixed https://github.com/spring-projects/spring-boot/issues/5127. I was wrong. We actually inadvertently supported both absolute and relative URLs. Indeed, the fix for https://github.com/spring-projects/spring-boot/issues/5665 introduced code that's very similar to what JarLoader is doing in terms of URL creation.

On the Boot side, I think this boils down to whether or not we want to support the, as far as I can tell, non-standard behaviour of honouring absolute paths in the Class-Path manifest attribute (I believe it's non-standard as the documentation quoted above only talks about relative paths).

In summary, we inadvertently used to support absolute URLs. That support was removed by this commit which moves us closer to what the spec requires but appears to have broken IDEA.

Given that this used to work, albeit inadvertently, I am leaning towards supporting the non-standard behaviour in Boot after all. Particularly if it's difficult to align IDEA with the spec or if my interpretation of the spec is incorrect.

[akozlova]

The only problem in IDEA is that the code is common for different test frameworks (such as mockito), applications, etc. This means that every change should be validated across of all of them. Let me see how they will survive.

[wilkinsona]

That sounds like a rather broad high-risk change. I've opened https://github.com/spring-projects/spring-boot/issues/10268 to change Boot's behaviour.