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?
Related
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.
I have an application that uses jaxws-api-2.2.8.jar and stax-api-1.0-2.jar. I see that these APIs are already included in standard JRE so I could mark them as provided in my POMs but I'm not sure which version of each API is included in each version of the JRE. Of course the problem arises with other API jars too. I've tried to find an "official" source of info without luck. Have you more info?
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.
I am migrating an application that used Jetty 7.4.5.v20110725 to Jetty 9.3.0.M2, using Maven. I already had upgraded the javax.servlet-api to 3.1.0.
But I am using the FakeHttpServer version 0.3.0 for tests, and at this time there is no newer version. It uses the org.eclipse.jetty.server.nio.SelectChannelConnector class that used to exist up to Jetty 8.x, but does not exists anymore in Jetty 9.
Currently my projects breaks at runtime with a NoClassDefFoundError due to the removed class in Jetty that FakeHttpServer tries to use, holding me back from upgrading Jetty. What can I do to fix that?
Note, this was also cross-posted in the Portuguese StackOverflow version: https://pt.stackoverflow.com/q/64548/132
Upgrade the code that uses Jetty on FakeHttpServer for Jetty 9.
That is your only choice if you want to use Jetty 9 with FakeHttpServer.
Looking at the project page for FakeHttpServer, it seems that there have been no updates (commits) to the project tree since Dec 2012.
You'll either have to convince the project leads to update it, or do it yourself.
Note that Jetty contains several ways of testing webapps. Look at the unit tests in the jetty source code and I'm sure you will find the equivalent of FakeHttpServer.
ServletTester comes to mind as one example. Or just create a Server using the LocalConnector is another way.
I am using Glassfish 3.1.2.2 to host several web applications, some of which use JodaTime. Recently, I've updated the version of JodaTime from 1.6.2 to 2.0. After doing this, I get problems with errors like this:
java.lang.NoSuchMethodError: org.joda.time.DateTime.compareTo(Lorg/joda/time/ReadableInstant;)I
Usually this indicates a dependency-crash on the classpath, but I couldn't find that my project had multiple versions of JodaTime, 2.0 was the only one. After some more digging, and debugging to find where the DateTime-class is loaded from, I found that it is loaded from [glassfish]\modules\joda-time-1.6.2.jar, which is of course not what I want.
Why does glassfish include a specific version of a library like JodaTime on the classpath of every application, and is it safe to remove it/replace it with version 2.0?
GlassFish doesn't include any version of JodaTime.
I guess you placed the jar file in [glassfish]\modules by yourself and forget that you did that. You can have a look at a fresh GlassFish installation to validate that.
It is safe to delete the old version from the modules folder.