/workspace file conflicting with a classpath resource

[jerzykrlkroche]

Dear team,

I noticed an unusual behaviour of a packaged Spring Boot application in a Kubernetes deployment.

When this file and dir are present in the /workspace:

• /workspace/config/application.yaml (added with a Kubernetes' sourcemap).

then it overlaps and replaces the default Spring Boot configuration file which is present here:

• /workspace/BOOT-INF/classes/config/application.yaml

I guess that the entire /workspace dir is on the classpath. Is this correct? Is this an expected behaviour?

What's would be the best place to put extra sourcemap files?

Thank you!

[fg-j]

@paketo-buildpacks/java-buildpacks any thoughts on this?

[dmikusa]

I guess that the entire /workspace dir is on the classpath. Is this correct? Is this an expected behaviour?

By default, yes.

When you build from source, the buildpack will run Maven/Gradle/etc. and build your JAR/WAR file. It will take that, store it, delete all your source, and then extract the contents of that file into /workspace. i.e. after build, /workspace is your exploded JAR/WAR.

When you build locally and pack build a JAR/WAR file (this is what happens when you use Spring Boot build tools), the JAR/WAR is extracted and the contents of it are pushed into the container at /workspace. The buildpacks then run, augment your app and produce the run image.

The net result is that in both cases, your /workspace is the exploded JAR/WAR. The app is run with java -cp /workspace:...

Not to be confusing, but there are other scenarios where this doesn't happen, like if your build produces multiple JAR files or if you include additional files from the build process, but these scenarios are less common. If you happen to be in one of these situations, then your app is run java -jar style.

then it overlaps and replaces the default Spring Boot configuration file which is present here:

I suspect that is a classpath ordering issue. When a resource is loaded from the classpath, it searches the classpath in order and stops looking when it finds a file, so if you have the same file in two locations on the classpath, the first location is going to win. Just guessing, but /workspace is probably earlier in the classpath.

What's would be the best place to put extra sourcemap files?

I would not volume mount/config map things into the /workspace directory. It's not strictly a problem, but you run the risk of colliding with existing files and folders. This would be another similar potential problem from doing that.

I would suggest that you volume map to a place that doesn't exist at all, like /config or some thing where you'll never have to worry about potential conflicts with a file in the container. That also lets you control things like should this location be on the classpath or not.

Hope that helps!

[jerzykrlkroche]

Good morning @dmikusa,

Thank you for your explanation. This helps a lot.

Can I ask an extra question - what tools do you use to troubleshoot the already built OCI images? I found this to be the hardest part - existing Docker tooling doesn't correctly show all details of the image, env variable declarations or the command. So I had to make a lot of guesses.

Thank you!
Jerzy

[dmikusa]

dive works well. It lets you look through the layers.

If you're on the base or full stack, you can also just docker run --entrypoint=bash <img> and it'll give you a shell in the container.

[jerzykrlkroche]

Thank you Daniel - I'll have a closer look at dive then.

Have a good day.