Spring Boot use case: using `spring-boot-loader` and classpath jar order
See original GitHub issueThank you @chanseokoh for this thorough and well written explanation ! You’ve made clear, precise and wise points that have changed my mind 😃.
We are using Jib with Spring Boot (and JLink, but that’s another topic) and are very happy with it. Please continue the good work.
As you say at one point it might be useful to have this kind of capability. One case where I think it might be useful is when defining our own entrypoint. When that happens we need to define ourself the java execution command, something like
# Retrieve the files present in the /app/libs directory before subsequently joining them with a ':'
LIBS=/app/libs/*
exec java ${JAVA_OPTS} -cp /app/resources:/app/classes:${LIBS/ /:} ${MAIN_CLASS}
In that case I think the spring-boot-loader might do a better job than us, since it will handle the classpath and the main class for us.
Also, although I’m not sure if it’s significant, Spring Boot now creates a classpath.idx
file providing the ordering that jars should follow when added to the classpath. At one point it might be a good idea to follow what is written in that file.
_Originally posted by @celcius112 in https://github.com/GoogleContainerTools/jib-extensions/pull/31#issuecomment-655584059_
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (5 by maintainers)
Top GitHub Comments
I’m just curious. Why do you expand file paths in
/app/libs
using a shell? If you pass the literal*
(without expanded by a shell), then JVM will expand it internally (will match*.jar
files only).And also we’ve heard a potential risk when listing all the dependencies on the command line, as some OSes may have a relatively short limit on command length (although I think in practice it’s very rare to hit this issue unless you have hundreds of dependencies rooted deep in paths).
I’ll keep it here, but with the note that this should be implemented as an extension.