Java compiler receives broken classpath when invoked within Spring Boot jar application

[villuv]

Original problem description, reproduction code and discussion is here: querydsl/querydsl#1407

Basically,

If Spring Boot application gets run with java -jar, classloader returns "nested jar" classpath entries, like

0 = {URL@2237} "jar:file:/Users/villuv/src/misc/springboot-querydsl-bug/target/springboot-querydsl-bug-1.0-SNAPSHOT.jar!/"
1 = {URL@2238} "jar:file:/Users/villuv/src/misc/springboot-querydsl-bug/target/springboot-querydsl-bug-1.0-SNAPSHOT.jar!/lib/spring-boot-starter-1.2.4.RELEASE.jar!/"
...

Now, this here https://github.com/querydsl/codegen/blob/master/src/main/java/com/mysema/codegen/SimpleCompiler.java#L69 deals with composing the classpath parameter for the compiler. And it seems to be unable to handle those "deep jar URLs" correctly. For example, classpath entry from classloader:

jar:file:/Users/villuv/src/misc/springboot-querydsl-bug/target/springboot-querydsl-bug-1.0-SNAPSHOT.jar!/

decodedPath becomes

file:/Users/villuv/src/misc/springboot-querydsl-bug/target/springboot-querydsl-bug-1.0-SNAPSHOT.jar!/

And following thing gets added to paths

/Users/villuv/src/misc/springboot-querydsl-bug/target/file:/Users/villuv/src/misc/springboot-querydsl-bug/target/springboot-querydsl-bug-1.0-SNAPSHOT.jar!

Notice that it keeps the file: scheme name in the middle of it and also prepends a full path even though the URL already is a full path.
Next up, pathJoiner will concatenate all these entries together, using : as path separator character. This means, classpath string that gets given to the compiler can't be decoded correctly.

[ShijunK]

might be related.

com.mysema.codegen.SimpleCompiler#getClassPath only check com.mysema.codegen.SimpleCompiler#isSureFireBooter for the first level of classloader passed in. Not for all the parent classloader.

It is a problem, when running a embedded tomcat (Spring Boot auto config) during integration test with Maven Failsafe plugin. The first classloader passed in is a "TomcatEmbeddedWebappClassloader" (isSurefireBooter returns false), its parent is sun.misc.Launcher.AppClassLoader (isSurefireBooter returns true, but it is never checked).

the workaround is: http://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html

on surefire or failsafe plugin, set "useSystemClassLoader" as false. which force Maven surefire uses plain vanilla classpath, instead of manefist classpath in booter file.

[xvipservice]

any one fix this?

[sfat]

@ShijunK any news on this guy?I just found out the hard way that while deploying this as a executable jar it does not find the correct classpath.
Not sure if this is repository is still active or I should move on finding something different. Does not seem to be much action lately.
I can help if I can, but I need some guidance.

[Shredder121]

In theory the repositories of Querydsl are still active. (I'm still actively developing)
In practice there are some hurdles that still need to be crossed.
Some other things, like Java 9 revamping the way class loading works are another issue.
So, first I'd like the holidays to pass and then I'll pick up the progress.
(But, yes, this issue sounds good to fix :/ )