I forced a rebuild of my Docker image, using docker build --no-cache because of issues with the way the Dockerfile pulls the code (uses tarball, instead of surrounding git working copy).
After I did this, and tried to start the Docker image, I got an error that the JRE and JRI had version mismatch:
mkdir -p /Users/rpg/projects/xplan/container-ontology/owl/server-files
cp container-ontology.ttl om-subset.ttl strateos-catalog-individuals.ttl /Users/rpg/projects/xplan/container-ontology/owl/server-files
cp owlery-catalog.xml /Users/rpg/projects/xplan/container-ontology/owl/server-files
rm -f /Users/rpg/projects/xplan/container-ontology/owl/server-files/.DS_Store
docker run --rm --env JAVA_OPTS='-Dorg.slf4j.simpleLogger.defaultLogLevel=DEBUG -Dlogback.configurationFile=/srv/conf/logback.xml' -p 8080:8080 -v /Users/rpg/projects/xplan/container-ontology/owl//server-files:/srv/owl -v /Users/rpg/projects/xplan/container-ontology/owl/owlery-conf:/srv/conf owlery:latest | tee server.log
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/jena/query/Query has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:650)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:632)
I am confused by this, since it looks like jena is still at version 4.1.0 in your new build.sbt file.
Looking at the Docker output, I think I had jdk 8 before and jdk 8 now. Is there any chance that sbt could have pulled in a separate JDK that's a higher version?
I forced a rebuild of my Docker image, using
docker build --no-cache
because of issues with the way the Dockerfile pulls the code (uses tarball, instead of surrounding git working copy).After I did this, and tried to start the Docker image, I got an error that the JRE and JRI had version mismatch:
I am confused by this, since it looks like jena is still at version 4.1.0 in your new build.sbt file.
Looking at the Docker output, I think I had jdk 8 before and jdk 8 now. Is there any chance that
sbt
could have pulled in a separate JDK that's a higher version?