I'am developing a webapp using google app engine and maven in intelliJ IDEA.
So far so good until I tried to send an email using javax.mail and I get this error:
java.lang.NoClassDefFoundError: javax/activation/DataContentHandler
I have already put the dependencies needed (javax.activation & javax.mail) in the pom.xml and still this error occurs.
One way to fix it locally is to add "--add-modules java.activation" in vm options and when i run it locally its working fine and sending the email, but when I'am deploying the app its not working.
And my question is,
is there any way to pass the vm argument to maven or anywhere else so it will run without the error when I'll deploy the app.
Or is there any other way to do this (with javax.mail or not) ?
My java version is: openjdk 10.0.2
Just include the java.activation module in your application.
You can use either the older Oracle version, or the newer Eclipse version, which is essentially the same.
(And you should consider upgrading to JDK 11.)
You could do that with docker containers.
How to properly set the JVM options in a flexible GAE application
Cause with maven you can not set the VM options for run time. Trying via docker could be key.
Related
I'm just getting started with Jenkins, and specifically i'm testing out a project that uses JDK8, and can't be upgraded to JDK11.
Now Jenkins as of July 2022 uses JDK11 internally, and I'm unsure how to get it to talk to an agent that uses JDK8, in order to build my project on said agent.
I'm using this guide, and i'm going down the jnlp route, so i'm spinning up a container per job (it's a freestyle job for now), using the jenkins/jnlp-slave:latest-jdk11 image, which seems to work fine. However when I switch to the jenkins/jnlp-slave:latest image (which uses JDK8), the container is unable to talk to Jenkins and I get this:
Inbound agent connected from 192.168.1.1/192.168.1.1:52636
java.lang.UnsupportedClassVersionError: hudson/slaves/SlaveComputer$SlaveVersion 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.lang.ClassLoader.defineClass(ClassLoader.java:635)
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:453)
Which implies Jenkins on JDK11 won't talk to an agent running JNLP JDK8. Now normally i'd know to just upgrade my JDK version, but that won't work here as my project specifically needs to build on JDK8.
How can I best resolve this? Modify the JDK8 docker image to use JDK11 to begin with but then switch on the fly via updating my PATH & JAVA_HOME to JDK8 when it comes to actually building my project?
Ideally i'd like to be able to build projects using either JDK8 or JDK11, depending on the docker image I pick for them.
I created a custom process listener for my jbpm and deployed the jar in artifact and built and deployed in project setting and gave deployment.xml resolver type as reflection and package name . classname in identifier
i'm stuck with this error when i try to build and deploy the jar in the project please help me guys.
The error i'm facing
classes with v59 are emitted by javac v15 (or javac v16 and up, if using the --release 15 switch). A java that complains about class files being higher than v52 is java v8.
In other words, you've compiled code to class files targeted at java 15, and are trying to run these on a java 8, and obviously that square peg does not fit into that round hole.
You have 3 available solutions:
Upgrade the java to java15 or up. That'd be the java running in that cloud / workbench thing.
Downgrade the java you're compiling with back down to jdk8. If the class file was e.g. produced on your workmachine, either learn how you configure which java is the default target, or if using an IDE edit the project settings, or if you can't figure any of this out, just uninstall it all and ensure only a java8 is installed. Not recommended.
Configure the build script (and, depending on how you've set things up, your IDE configuration) that you want to target java8. If you're using javac on the command line, this boils down to adding a --release 8 option when compiling. Find the equivalent of that for maven, gradle, eclipse, intellij - whatever you are using.
Any one of these options will fix your problem. The list is exhaustive.
I had the same issue. I was creating the docker image with java 11 version and trying to deploy it with java 11 on Kubernetes using kubectl commands.
How I fixed it: I need to create the docker image again with java 8 version afterthat I moved this image to docker hub and deploy it on Kubernetes.
I have an app engine project in Eclipse. I have kept a JSP file in WAR folder. I have given the path in the installed jre as JDK1.8. Now when I run the project in local the JSP file successfully loads after clicking on a hyperlink. The same project after deployed to Google App Engine fails to load. It shows server error.
What I thought as the possible cause: I read some where that Google AppEngine now supports JAVA 7. So when I compile the JSP file in JDK1.8 in local it worked fine. But the problem occurred when I deployed the project in cloud. I think, it could not compile JSP files.
Please suggest me what you think ? Is it because of same cause ?
As per the documentation available, "App Engine runs your Java web application using a Java 7 JVM in a safe "sandboxed" environment.". So that is as far as the runtime is concerned. It does have a backward compatibility for Java 6 applications for now.
However, keep in mind that the App Engine SDK now supports only Java 7. And ideally I would not go with JDK 8, where things are still in the works.
Behind the scenes, when you upload your application to App Engine, they know which Java runtime to use based on the SDK JAR that you have linked. So ideally, that is taken care of for you.
So, I still believe that though you have provided JDK 1.8 locally, the App Engine version JAR will be enough for Google to deploy your application in an appropriate Java 7 JVM and things should have worked if it is just a simple JSP that you are trying to link up.
Since you have not given details on what the JSP does, it would be good to know that since that could give some pointers. Additionally, I suggest that you allow for DEBUG logs and visit the Admin Console logs to understand what is going wrong. That will give you more details.
I had exactly this problem; including even one JSP file, even with no Java code or any content at all, would prevent my appengine instance from starting.
The solution was to make sure you start Eclipse using the 1.7 VM, even if you're developing against the 1.8 JDK. Because my Eclipse instance was running in the 1.8 VM, the generated JSP files were incompatible with AppEngine.
You change the host VM in the eclipse.ini as shown here: Google App Engine JSP can't deploy: java.lang.RuntimeException: Cannot get the System Java Compiler. Please use a JDK, not a JRE
I am a newbie w.r.t. jetty and RESTful API's.
I want to create REST services using Jetty and wants to use embedded jetty with eclipse.
Can anyone suggest me any HowTo for installing Jetty/ Jetty plugins with Eclipse in Mac OS.
Regards,
If you're looking for an Eclipse plugin that will allow you to start your web app in Jetty via the Debug/Run menus, you may want to take a look at the run-jetty-run plugin.
If you happen to be using Maven, there's a Maven plugin you can use to start your app in Jetty as well. This can be configured to run via a launcher in Eclipse or can be launched via the command line.
Edit - Added more info about the jetty-maven-plugin:
If you're just talking about local development, then you don't have to download Jetty separately for use with the Maven plugin. The Maven plugin handles the download of the dependencies that you need by simply running mvn jetty:run. This will start your web app in Jetty (by default) at http://localhost:8080. If you use this, then there's really no need for the Eclipse plugin, either. As far as versions go, these are the available versions. I'd recommend sticking with a fairly recent version unless you have a need to use an older version of Jetty (it looks like the most recent version is a release candidate--8.0.0.RC0).
There's also an example of usage in a project on Github that I just found, but you may want to update the plugin version used.
am developing a simple web app using jsps and servlets for tomcat 5.5.
Currently using the Eclipse Helios and Dynamic Web Application Project.
For some reason it is a nightmare. We spent 4 hours today trying to deploy a servlet to tomcat. We kept getting errors like
"java.lang.UnsupportedClassVersionError: Bad version number in .class file"
we played around with everything trying to set the build compatibility to what tomcat had but couldn't make the stupid thing work. (Yes it is possible we're incompetent. any suggestions on what we can try looking at are apprecieated)
My friend recalls from long time ago that he used this plugin
eclipsetotale_tomcatPlugin
in order to create a "tomcat project". My question is, does sysdeo tomcat plugin add any features that aren't already available in helios?
thanks
Not sure about sysdeo, but your error seems similar to bug 116713:
If your default JRE is set to 1.4.2 and you have a Web project targetting
Tomcat 5.5 (dynamic Web module version 2.4 and Java 5.0), when you tried to run
a main program, you'll get the error (you mention).
What is your default JRE set for your project?
This scenario happens when the JVM running the code is older than the one the compiler generated code for.
Have you considered simply running Tomcat under Java 6? If that is not an option, please edit your question to include this and any other restrictions on this project.
We used to get that error often when we had Java version issues. Eclipse environment and Windows environment (java_home and path variables typically) are easy to overlook.
Also, you can use javap -v Foo in same directory as Foo.class to find out its version.
Just use the Eclipse IDE for Java EE Developers, 206 MB edition of Eclipse. It has Tomcat and other webserver support built-in by default. Works like a charm!
Sysdeo is an old, as far as I know obsolete, plugin.