java.lang.NoSuchMethodError: jodd.Jodd.init(Ljava/lang/Class;)V - java

I am trying to use the Jodd-http version 3.6.6 library in a simple application. The application runs fine on a test machine which has java 1.8 installed but when I try to run the same application on another machine with java 1.7 it throws this excption.
java.lang.NoSuchMethodError: jodd.Jodd.init(Ljava/lang/Class;)V
is this version of jodd-http is not compatible with java 1.7?

Jodd modules are distributed in two flavors:
1 .as a single bundle jar, that contain all Jodd modules in one distribution archive.
separate jar for each module.
So Jodd may be used on any platform where there is a suitable Java 7+ runtime environment.

This shouldn't be related to java version, but to existance of jodd libraries - are you sure you have jodd-core jar in your classpath?
Because jodd-http can't work without jodd-core:) And from your exception it looks like only jodd-http jar is present in the classpath; but not jodd-core.
Can you check this please?
I don't know if you use maven repo (jCentar or Maven Central), but it would be good so all this dependencies can be loaded automatically.
EDIT:
Check httpclient example in the https://github.com/oblac/jodd-quickstart
EDIT:
Check the classloaders - if they see the Jodd class (or any class from jodd-core); maybe the classloader for some reason dont see it; or there are multiple different versions of jodd-http on the classpath.

Related

How best to provide JAXB components in an RCP application

My RCP application makes calls to SOAP web services and has been using the built-in JAXB/JEE components in Java 1.8. I have set up the build process to force the use of Java 1.8 and this had been working well.
Recently, the build stopped working because the builder (Tycho) now has a component which only works with later Java versions. If I compile with the later version I get 100's of JEE-related errors such as JaxbElement not found or #WebMethod not found.
At some point we will have to move away from Java 1.8 and use a Java version which does not provide those JEE components, so forcing the use of 1.8 can only be a short-term solution.
Is there an eclipse plugin which already provides those missing components? (I have searched but not found anything) Or do I need to create my own helper plugin which contains the necessary libraries? Is there perhaps a JAXB alternative which I could use for the SOAP calls?
The JAXB plugins/bundles are available on Eclipse Orbit: the plugins/bundles starting with javax..
In the plugins/bundles where they are needed, add the dependency in the MANIFEST.MF file via Import-Package (using Require-Bundle would require that these plugins/bundles are available even when using Java 8).
See also this answer.

Java-Maven-IntelliJ: How to define a "portable" JDK that is bundled with the project as the SDK/JRE to compile and run?

UPDATE: Looks like it's not possible yet: https://youtrack.jetbrains.com/issue/IDEA-240044
I'll update the question with an answer, once this issue is resolved (this way or the other)
I have a super-special version of the JDK customized to compile and run a desktop client I am providing as an IntelliJ project (with source).
Users of my client can't get it to work with the Java they have installed on their work stations by our corporate IT.
On the other hand, they need that standard Java to run other things. The custom JDK is not good for running the other Java applications our corporate requires (so, I can't just have my JDK as their system-wide JDK).
Also, the work stations of my users do not support containerization.
So, I am thinking to bundle my JDK with the project and configure it to use that SDK. This is going beyond just preparing a "setEnv.bat" script with "JAVA_HOME=/xjdk" for many reasons, like being able to debug using the IDE, when the IDE is debugging code compiled with the special JDK...
I know IntelliJ has places to set up the JDK and JRE but not sure how to do this in a "relative path" way and such that will run on both Mac/Win without them having to configure the project for the absolute path of the bundled JDK?
Assume the project structure is something like this:
ProjectFolder
|_ src
|_ xJDK
What IntelliJ/Maven elements do I need to set to get both compile and run using xJDK?

Packaging a particular version of java with my code

I've built a standalone Java Maven app. I need a particular version of java for running my code e.g. 1.8.0.155. My target environment has an older version. E.g. 1.8.0.45.
For various reasons I'm unable to get the target system to update their version of java.
How do I just bundle a version of the jdk along with my jar?
What you're looking for is how ot create a self-contained application, this link is how you do it without any third part assistance. Another option is Launch4j, a third party wrapper.

Build web service with jax-ws reference implemetation bundled in JDK 6

I used to saw a tutorial about this topic. But when I try to make my example application by following the example. I can't find com.sun.xml.ws.transport.http.servlet.WSServletContextListener on my classpath.
but I found com.sun.xml.internal.ws.transport.http.servlet.WSServletContextListener
It confused me, why Oracle move those classes in com.sun.xml.xxx to com.sun.xml.internal? I am using JDK1.6.0_45. I saw some people said, form JDK6U4, jax-ws reference implementation is bundled in JDK, so we should be able to publish a web service by running a light weight http server just with JDK and no other dependencies needed, is that ture? You should notice that in the tutorial I mentioned above, additional dependencies is still needed, see step 5 "JAX-WS Dependencies".
And I also found that in IBM JDK, even com.sun.xml.internal.ws.transport.http.servlet.WSServletContextListener can't be found.
Yes, JAX-WS RI (same as JAX-B RI) is shipped with JDK since Jdk6. All the packages except for javax.xml.* are changed to .internal. in order to avoid conflicts between JDK's and standalone JAX-WS versions.
Using JDK's version, you can deploy web service using just JDK; if you want deploy WS in tomcat or in some AS, you still need JAX-WS standalone version.
If you check grepcode for (non-internal) WSServletContextListener, it shows you, the class is shipped with jaxws-rt/webservice-rt jar.
By looking for the internal WSServletContextListener, you can't find a jar shipping it. (but grepcode also contains the sources of openJDK)
Also, I tried to find WSServletContextListener in my local jdk7, but can't find it. But maybe some third-party jdk ship with the class.
Anyway, if you look into the tutorial again, you will find that jaxws-rt.jar is necessery for the application. Probably you should add it?

JRE version enough to run a jar

What is the smallest version of JRE to run a simple jar that calls other jars while running ?
That depends completely on what parts of the Standard API and what class file version the classes in that JAR (and the ones it calls) are using.

Categories