docker scan classpath not working

Hi,

following code for scan all classes in a package recursively works fine but when I dockerized my application, that doesn’t work no more.

ClassPath classpath = ClassPath.from(Thread.currentThread().getContextClassLoader()); for (ClassPath.ClassInfo classInfo : classpath.getTopLevelClassesRecursive(packageName)) { }

I constated by investigating the code that results of url packages are jar:file:/frame-socket-connector.jar!/BOOT-INF/lib/log4j-core-2.7.jar!/ in docker instead of
/home/christof/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.7/a3f2b4e64c61a7fc1ed8f1e5ba371933404ed98a/log4j-core-2.7.jar when I launch my application directly with gradleBootRun.

any idea?

[lorthirk]

I am also facing this issue, and I think this is because the final packaging you’re having inside the Docker container; in my case it’s a Spring Boot application, but anyway we’re both having a fat jar as a result. As you already noticed, in the fat jar deployment the classes are coming from jars who, in turn, are put in the main jar: you can notice this from the jar:file: prefix. Unfortunately this is not supported by ClassPath, according to the Javadoc:

Warning: Current limitations:

• Looks only for files and JARs in URLs available from URLClassLoader instances or the system class > loader.
• Only understands file: URLs.

You can also check the actual code here. Unfortunately I still couldn’t find a solution with Guava. If someone has some other alternatives, please let me know!

[LukasSmrcka]

I am currently facing the same issue. Any progress in this?