I am struggling for a few days to write a docker-compose file for a simple jakartaEE/JavaEE restful JPA web application. DB is PostgreSQL and the application server is payara. This application inserts few entries to the DB and returns the collection in each rest call response. When I deploy the same application in the locally installed payara and Postgres, it is working fine. But it is failing with docker-compose with the error:
An error occurred during deployment: Class
com.docker.java.petstore.service.PetstoreService has unsupported major or
minor version numbers, which are greater than those found in the Java
Runtime Environment version 1.8.0_222. Please see the server.log for more details.
https://imgur.com/a/zVvVaGP
I tried deploying the war file from the payara admin console but failed with the same error.
The relevant code is shown here in the gist:
https://gist.github.com/JohnyzHub/cf8e9560b8640dbfd27dc4bb98d5991c
The environment used:
java 11
JakartaEE 8
Payara appserver
postgresql
Using glassfish-resource.xml file for dynamically creating the connection pool and data source.
The error looks strange, I am using java 11 but the error is about a specific java 8 version. I am not getting any clue what could be wrong here.
When I deployed the similar java 11 web application without JPA layer with a same docker file, it is working fine on docker.
Let me know if additional details are needed.
Any help is appreciated.
The official Payara Docker images on Dockerhub are using Java 8 inside. This clashes with your Java 11 compiled source code and does not work.
There is an open issue for this on GitHub, but unfortunately, now answer for months.
As a work-around either pick another application server (e.g. Open Liberty Universal Base Docker images have tags for the latest Java versions) or build your own Docker image from e.g. an OpenJDK 11 base image.
To figure out how to create your own Docker image, I would suggest to have a look at Adam Bien's Docklands repository, which contains multiple examples.
The error of your server says you compiled the classes in a higher version (JDK11) than its currently using (JDK8) in the docker image.
Check the used Java Runtime on the Application Server Docker image.
Then either compile the petstore using that JDK8 version of the server, or upgrade the docker container image to use a higher JDK than the one used to compile.
Related
I'm really new to Docker and wanted to setup a Wildfly-Container (v26) and deploying a .war-File to it.
The problem I've encountered is, that Wildfly is using JDK11 as base image.
My program was written in JDK17. I've found this to change the JDK and the wildfly is running, but I have no idea if it worked. Is there any command or way to read out the used java version the docker image of wildfly is now using?
Sure I could 'just deploy' the war, but I have no access to the admin console. It looks like there is another problem I have to fix before.
I have an application running on jdk7 and jboss and i would like to extract all the batch code from it to make it cleaner.
I want to create executable spring boot 2 jars and run them separately or at least upgrade to spring boot and the jdk version to 8.
Is it possible to run a spring boot 2 application that requires jdk 8 on a machine that also runs a jboss application on jdk 7 ? how can I specify the jdk version at runtime for an executable jar or war ?
I would like to use a container to solve this but our production team doesn't want that right now. I know there is "setenv" in a tomcat or weblogic servers but i would like to know if there is a spring boot solution for that (I didn't find any)
Thank you in advance.
You can have as many JVMs as you like on your machine. you just need to have the settings for the java version you need to be loaded.
ie if your java 8 is in c:\programs\java\jdk8\bin and your java 7 is in c:\programs\java\jdk7\bin, then you need to specify the java.exe absolutely as in c:\programs\java\jdk8\bin\java.exe you also need to set the environment variables for that session, like set JAVA_HOME=c:\programs\java\jdk8\bin\.
My example is using a windows machine as a base. You will need a startup script, or similar for the environment that you are using.
Note that if you just use java.exe in your startup script, then the JVM will be started with the first JVM found in your %PATH%, so you may want to remove Java from the path to be sure that you are getting the exact version you require.
Dear Java & Docker Masters,
Have you encounter issue that pulls out your hair? Try this:
I have a Java Spring Hibernate web application that able to run successfully on my local that build via Gradle. IT is compile using Oracle JDK 1.8.0_101. It runs under Tomcat 7.0.72 (and tomcat runs Open on JDK 1.8.0_102). It runs the war perfectly well. Why do I have such different jdk version? because i want to mimic the dev server below.
My Dev server is a docker under aws ecs, with only one container image. And this container image uses the tomcat:7.0.72-jre8 image base. The same war application that is running inside the container throws the following error:
Error creating bean with name 'agencyRepository': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Not an managed type: class com.mnetmobile.data.entities.Agency
I drag that war file, and runs on my local, and it works like a champ. All JDK versions are the same, tomcat version are the same. the only thing different, is a windows 7 laptop, vs an ubuntu linux and runs docker. (All the path different is N/A because there are all relative path)
Any idea which hole i might have missed?
Somehow there must be some difference in the configuration of the two Tomcat servers. Since the Java version, the Tomcat version, and the war file are all the same; there must be some difference in the Tomcat configuration, either in the Tomcat lib folder, or the context.xml or server.xml or someplace.
I've been on a very old version of GAE for a long time. Every time I try to update to the latest version I get this error when deploying it to GCP:
java.lang.IllegalArgumentException: Class file is Java 8 but max supported is
Java 7: org/eclipse/jetty/http/BadMessageException.class in C:\Users\XXXXXXXXXXX\
backendservlet\build\exploded-app\WEB-
INF\lib\jetty-http-9.3.2.v20150730.jar
I think jetty comes with GAE so how do I fix this? When I deploy it locally it runs without errors. It also builds without error. This only happens when deploying to GCP.
My appengine instance is on JAVA 7 runtime so maybe that's the issue? How do I change that? I tried deplying with a different version and name and it still didn't work.
Please help.
Looks like jetty (or at least the version you're using) needs Java 8, which is not supported on GAE: Does Google App Engine support Java 8?.
GAE does not yet support Java 8. If jetty is a dependency of your project, you need to use a version that has source 1.7. Otherwise delete C:\Users\XXXXXXXXXXX\
backendservlet\build\exploded-app\WEB-
INF\lib\jetty-http-9.3.2.v20150730.jar
I try to create an enterprise application client with JBoss by following this official tutorial (based on Glassfish):
https://netbeans.org/kb/docs/javaee/entappclient.html
but I get this error message: Error: Unable to access jarfile C:\EntAppClient\${client.jar}
As far as I know, Netbeans IDE supports JBoss 7 since its version 7.3 RC1 and I use Netbeans 7.4. This feature seemed already broken for a long time according to this thread:
http://forums.netbeans.org/topic40270.html
It is expected to work as Netbeans is intended to support other application servers. However, some Glassfish specific properties are hardcoded inside the Ant build scripts and the property client.jar is set if and only if j2ee.clientName isn't set which isn't my case (it's set to EntAppClient.jar).
When I set client.jar to ${dist.dir}/${j2ee.clientName}, I go a bit further but Netbeans doesn't find the JAR of the remote interface and the Glassfish specific agent class loader org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader.
How can I make it work? I'm going to try to fix build-impl.xml to use the correct classpath and I hope to find a smarter solution.