Docker Community Forums

Share and learn in the Docker community.

Java can't find jarfile in Docker container running under Windows with mapped volume


(Andrewrmiller) #1

Docker for Windows Community Edition
Version 18.06.1-ce-win73 (19507)
Windows 10 Version 1803 (OS Build 17134.286)

Summary
We are using docker-compose to create four containers that work together. The docker-compose configuration was authored on a Linux system and works fine there. But on a system running Docker for Windows as the daemon and using Windows Subsystem for Linux (WSL) for docker + docker-compose, the Java container in our set fails to load .jar files.

Details
We use docker-compose to spin up four containers–two for Mongo, one for our Node.JS front end and one for our Java-based back end. The first three are operating without any issues. The fourth instance, the Java back end, is haviing issues loading jar files using the java -jar <jarfile> syntax.

Both the front end and the back end get their source from the host by mapping the source tree directly into the image using the volume option in the docker-compose.yml file. The front-end works fine (i.e. Node.JS can load all the files that it needs to). But when java on the back end container tries to access the files that have been mapped into the image we see the following:

Exception in thread "main" java.lang.IllegalStateException: java.lang.IllegalArgumentException: File /home/spring-boot/application/target/backend.jar must exist

Problem is, the file does exist. docker exec-ing into the container I see the file there. But sure enough if I try to run java -jar backend.jar from the directory containing the file I get the same error. Java just doesn’t see it (or so I am led to believe).

Have searched the Internet but have had no luck figuring out what might be going on here. Any help would be greatly appreciated.

Here’s what I am seeing when I log into the container and try to run the .jar file directly:

root@c8495988284a:/home/spring-boot/application/target# ls -l
total 43584
drwxrwxrwx 2 root root        0 Sep 27 20:02 antrun
-rwxr-xr-x 1 root root 22309047 Sep 27 20:07 backend.jar
drwxrwxrwx 2 root root        0 Sep 27 20:02 classes
drwxrwxrwx 2 root root        0 Sep 27 20:02 generated-sources
drwxrwxrwx 2 root root        0 Sep 27 20:02 generated-test-sources
drwxrwxrwx 2 root root        0 Sep 27 20:02 maven-archiver
drwxrwxrwx 2 root root        0 Sep 27 20:02 maven-status
drwxrwxrwx 2 root root        0 Sep 27 20:02 surefire-reports
-rwxr-xr-x 1 root root 22309047 Sep 27 20:02 svc-backend-0.0.1-SNAPSHOT.jar
-rwxr-xr-x 1 root root     4100 Sep 27 20:02 svc-backend-0.0.1-SNAPSHOT.jar.original
drwxrwxrwx 2 root root        0 Sep 27 20:02 test-classes

root@c8495988284a:/home/spring-boot/application/target# java -jar backend.jar
Exception in thread "main" java.lang.IllegalStateException: java.lang.IllegalArgumentException: File /home/spring-boot/application/target/backend.jar must exist
        at org.springframework.boot.loader.ExecutableArchiveLauncher.<init>(ExecutableArchiveLauncher.java:41)
        at org.springframework.boot.loader.JarLauncher.<init>(JarLauncher.java:35)
        at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
Caused by: java.lang.IllegalArgumentException: File /home/spring-boot/application/target/backend.jar must exist
        at org.springframework.boot.loader.data.RandomAccessDataFile$FileAccess.openIfNecessary(RandomAccessDataFile.java:234)
        at org.springframework.boot.loader.data.RandomAccessDataFile$FileAccess.<init>(RandomAccessDataFile.java:216)
        at org.springframework.boot.loader.data.RandomAccessDataFile$FileAccess.<init>(RandomAccessDataFile.java:206)
        at org.springframework.boot.loader.data.RandomAccessDataFile.<init>(RandomAccessDataFile.java:49)
        at org.springframework.boot.loader.jar.JarFile.<init>(JarFile.java:86)
        at org.springframework.boot.loader.archive.JarFileArchive.<init>(JarFileArchive.java:60)
        at org.springframework.boot.loader.archive.JarFileArchive.<init>(JarFileArchive.java:56)
        at org.springframework.boot.loader.Launcher.createArchive(Launcher.java:129)
        at org.springframework.boot.loader.ExecutableArchiveLauncher.<init>(ExecutableArchiveLauncher.java:38)
        ... 2 more

root@c8495988284a:/home/spring-boot/application/target# ls backend.jar
backend.jar
root@c8495988284a:/home/spring-boot/application/target#

And here’s a snippet from the docker-compose file:

  backend:
    image: "maven:3.5-jdk-10"
    working_dir: /home/spring-boot
    environment:
      MONGODB_URI_LOCAL: mongodb://root:example@mongo
      env: dev
    volumes:
      - ${SRCROOT:-.}/svc/backend:/home/spring-boot
    expose:
      - "8080"
    ports:
      - 8080:8080
    command: "java -jar application/target/backend.jar"

(Purplep) #2

Stumbled on the same error. I have the same docker for windows build. Tried edge version - it doesn’t help. What’s weird is that if I build jar inside of a container it works. If I build jar on another machine and use it inside of a container - it also works. I wonder whether this is a bug in windows, docker for windows or java…


#3

I have the same sort of problem. I map a folder on my host machine to be a volume in docker using docker run -v. For most of the tools that I run in the container this works fine. But for some tools it fails.

I’m building code inside a docker container. I created a Docker for Windows image that includes build tools for building Windows applications. I run the container to map in the USERPROFILE (which has nuget packages) and the application source code. For most C# .Net applications this code builds fine. I’ve not seen any problems with this configuration and msbuild, csc, and other associated build tools works. But now I’m trying C++ native code apps and I’m hitting errors.

Error message says fatal error C1041: cannot open program database 'C:\AgentWork\32\i\obj\calcmanager.vcxproj_1174148162\Release\x64\CalcManager.pdb

If I xcopy the source code to a folder inside the container the build succeeds.

I’m certain (nearly) that nothing else has the pdb file open, unless it’s the docker daemon and volume manager itself.