I have a web service and I'm using the Endpoint.publish("http://0.0.0.0:8080")
Thing is that JAX-WS 2.0 and 2.1 is affected by an issue that throw a NullPointerException when executing endpoint.stop().
The issue is fixed in 2.2 but when adding the dependency in the pom.xml publishing fails due to a java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String; since I'm using java 1.6.
The workaround is to add to the endorsed folder some libs. But I want to pack it all in jar-with-dependencies. An executable java jar.
Said this, I would be thankful if you help me:
Publishing the endpoint in 2.0 or 2.1 listening to all addresses (0.0.0.0)
or
Configuring dependencies in maven to pack everything using 2.2.x
but executable with JDK6
EDIT:
Requirements are a deliverable jar. A single jar that pack all of the dependencies (2 so far, about a 400k jar).
But if you think that the only way to make it work is to add an external shell script please let me know too.
Thank you!
The executable jar format does not allow for endorsed folders required for JAX-WS replacement (and neither does the Java WebStart launcher apparently).
You need to use something that can construct and execute a new "java" command on the fly. The best way from here is most likely to look for an installer which can run the program directly without needing to install.
What exactly do you need to happen?
EDIT: As the requirement is a runnable jar you simply cannot do this with JAX-WS 2.2 Find a workaround with the JAX-WS present in the latest release of the Java version you are targetting.
It is very nice that the JAX-WS stack ship with core Java allowign for very small deployments, but a pain that you cannot easily provide your own.
Note that you can provide your own with Java 5 but then you need to bring your own Endpoint implementation.
Do you need to use the JAX-WS RI? You could use CXF instead which is a fine JAX-WS implementation and doesn't suffer the same collision problems as the RI.
Edit: You could try to generate the classes with the RI, but use CXF in the deployment. JAX-WS is a spec after all so it should work...
Related
I'm developing an application that should run on a server. The application uses some external jars.
I have build the application and run it on a local machine without a problem.
Now, I need to deploy it on the server. The server has some of the jars located.
What should I do to make my application work on the server, using the jars that are already there?
I don't have much experience with Java, but I understand that there is a manifest file which has a class-path field that points to all the jars needed. Should I change the manifest "manually", so that it points to the location of the jar on the server? What do you do in situations like this, what is the correct procedure?
Also, if I use one version of jar during development, and there is a bit older version of that jar on the server, what should I do to perform the deployment correctly?
And what is the procedure in case of using maven, should I copy the jars from where it locates them on the local drive to one directory, or is there a way for maven to do it itself?
I'm using NetBeans btw.
Thanks
Re "using the jars that are already there":
See Introduction to the Dependency Mechanism, Dependency Scope: "provided ... indicates you expect the JDK or a container to provide the dependency at runtime."
Re "there is a bit older version of that jar on the server":
Update the library on the server or use the older when developing. I'd consider it a really bad idea to use different versions of a library for developing and runtime. This can lead to subtle errors that are hard to identify.
Re "And what is the procedure in case of using maven":
Does the introduction linked above help you in answering this as well?
Maven is supposed to work the same with any type of IDE.
I have a wsdl file for the Web service. I want to test the interaction between the client and the server. To do this, I run the mock server with embedded grizzly.
The question about of implementing mock server. I generated an interface from wsdl (and xsd) using the wsimport and wrote implementation. When run on the grizzly, I get the following error:
com.sun.xml.ws.server.ServerRtException: [failed to localize] cannot.load.wsdl(META-INF/wsdl/test.wsdl)
I run a web service with this code:
HttpHandler httpHandler = new JaxwsHandler(new TestImpl());
server.getServerConfiguration().addHttpHandler(httpHandler, "/test");
The problem is that Grizzly can not find wsdl and xsd files. In embedded glassfish its work.
EDIT1
I change wsdlLocation to "test.wsdl" and its work. But now grizzly say:
java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String;
EDIT2
If use JDK1.7 it works. But I need a JDK 1.6
I'm not sure why you're seeing that error. I can run the Grizzly jaxws example and obtain the wsdl using either 1.6 or 1.7.
I would recommend reviewing the source1 of the example and compare to what you have.
I'm change the jdk6 to jdk7 and works fine! Don't forget to change the JAVA_HOME and the default JDK of Netbeans as related here: How to set the JDK Netbeans runs on?
Your version of Grizzly expects a JAX-WS 2.2 API while JDK 1.6 ships with JAX-WS 2.1. As others mentioned, some of these files need to be installed into an endorsed directory. You can download the required files here or take them from your Grizzly installation. The download includes an Ant build file that provides a build target to install the files into the JDK endorsed directory. You can run it with ant install-api. If you cannot run Ant, you may install them manually:
cp lib/jaxb-api.jar $JAVA_HOME/lib/endorsed
cp lib/jaxws-api.jar $JAVA_HOME/lib/endorsed
Do not install other files from the JAX-WS distribution into the endorsed directory unless you want to create some really difficult to debug bugs for yourself.
I am suggesting to use the endorsed directory in $JAVA_HOME/lib/endorsed because that will work with most tools and applications without any additional changes. Others already suggested more targeted changes, such as setting an endorsed directory during a Maven build or copying the files into a Tomcat endorsed directory. All these approaches are fine as long as you can make sure that your code is picking up the right endorsed directory.
As a result, we had to use endorsed mechanism. Documentation
create a folder called endorsed and put these jar files in it
1.jaxb-api-2.2.jar
2.jaxws-api.jar
put the folder in tomcat server as
C:\tomcat-7.50\< created folder>
and run it will works
Changing JDK from 1.6 to 1.7 worked for me.
this is a follow-up post to the twitter discussion i had on Google App Engine (Twitter Conversation)
The Problem is that Jersey and GAE won't work together with datanuceleus 2.0, since GAE needs ASM 4.0 but Jersey needs 3.1. A detailed description and easy solution on that is available here: GAE and Jersey Problem description
There are several posts on questions here on Stackoverflow, so I opened this thread to collaborate with Google's Teams to solve this issue.
I simply switched from Datanuceleus 2.0 to 1.0 and Jersey was working again. Do you have any other suggestions? Especially since 2.0 would be great to use.
Greetings,
Mario
Another solution is to use version 1.18.1 of Jersey, which is no more dependent on asm 3.0 and contains a repackaged version of asm, you can check it here: http://mvnrepository.com/artifact/com.sun.jersey/jersey-bundle/1.18.1
This will work in GAE.
You should try jarjar, which embeds a jar into another jar and fixes code references on bytecode level.
See this excellent blogpost: http://blog.harrywye.com/post/30160964741/running-java-jersey-with-jdo-3-0-on-google-app-engine
As #peter-knego said, with jarjar is really easy, and you can still use JDO/JPA > 1.0
Download jarjar
Create a text file: testrules.txt with the following content:
rule org.objectweb.asm.** org.objectweb.asm3.#1
With asm-3.1.jar and jersey-server-1.1.5-ea-SNAPSHOT.jar (or whatever you have) execute the following commands:
java -jar jarjar-1.4.jar process testrules.txt asm-3.1.jar asm-3.1r.jar
java -jar jarjar-1.4.jar process testrules.txt jersey-server-1.1.5-ea-SNAPSHOT.jar jjersey-server-1.1.5r-ea-SNAPSHOT.jar
And finally just replace the asm-3.1.jar and jersey-server-1.1.5-ea-SNAPSHOT.jar with the repackaged libraries.
I am using it with the 1.8.3 SDK and it worked to me.
Reference here
I am new to Java and experiencing problems understanding exceptions thrown by the framework.
Right now, I am trying to implement a regular expression validator into an application consisting of Java 5 EE with myFaces 1.2 and Tobago running in an apache tomcat 5.5.
I followed a couple of tutorials (including the Java 5 EE tut from SUN) and came pretty far. However, when calling my jsp, I get the following error message:
java.lang.LinkageError: loader constraints violated when linking javax/faces/validator/Validator class
Can anyone explain to me what I need to do to solve this problem?
So far, it seems as if MyFaces 1.1.7 has a version conflict to TomCat 5.5. Both contain javax.* packages (one of them namely javax.faces.validator). The validator class has a different version in the packages. The corresponding MyFaces library is called myfaces-api-1.1.7.jar and the TomCat library is called javaee.jar.
The included javax packages in the myfaces lib is a subset of the packages from within the javaee lib. However... I cannot skip any of both, because the project will fail to start then.
Any tipps?
This is almost certainly caused by your application having its own copy of Validator (in one of its JAR files), and this is clashing with the server's own copy. Something this can cause a LinkageError.
Find out which of your WAR or EAR's JAR files contains that, and remove it (along with the rest of the javax.faces classes).
Sounds like a classpath problem. Check your classpath for two jars with conflicting versions (both containing the javax.faces.validator.Validator class)
According to the MyFaces homepage. Tomcat Config: Tomcat 5.5.x
Some users have reported problems when
using MyFaces with Tomcat 5.5.x. Here
is a short guide that will hopefully
help you not run into the same
problems :-)
If your are using the binary version
of MyFaces: MyFaces is packaged so
that it works with Tomcat 5.0.x so
the WEB-INF/lib/jsp-2.0.jar and
WEB-INF/lib/commons-el.jar JAR files must be removed from your
WAR files (including the examples).
If you are building from source: If
you want to build MyFaces from scratch
to work with Tomcat 5.5.x, you have to
set the property
tomcat.pre.5.5.version in the
$MYFACES_HOME/build/build.default.properties
file to the value false.
Perhaps you've got two conflicting versions of the same library available on your classpath. For example, you might have a jar file in WEB-INF/lib that's already provided in TOMCAT_HOME/lib. (el-api.jar is a common culprit, but there are other possibilities.)
I haven't been using Java extensively hence forget a lot fundamental things. Basically, I am working with a web-dynamic project (using Eclipse IDE with jdk 1.6), and during the build, I get errors that Cookie class and other web related classes cannot be found. What am I missing?
What Jars files do I need to add (and how)?
thanks
Think you need servlet-api.jar
Try here for any jar files you need http://www.java2s.com/Code/Jar/CatalogJar.htm
Sounds like you are missing servlet-api.jar
You can download it from the Maven repository.
Servlets are only part of the Enterprise Edition, not of the Standard Edition of Java. So you need the Java Enterprise Edition, AKA Java EE.
http://java.sun.com/javaee/
As others have said, you're missing the server api jar.
Having said that, downloading just the servlet api jar and not the server that goes with it means that you can't actually test your code.
In Eclipse, once you're installed a servlet container, such as Sun's Glassfish, Apache Tomcat, or Jetty, you can create a server instance of it so that Eclipse will compile against your server's servlet implementation. Creating a server instance also means that Eclipse's Run on Server command works.
IBM has a slightly outdated guide on Developing Web applications with Tomcat and Eclipse. The entire "Install the Web tools" section can be skipped if you have the Eclipse EE version, as Web Tools are already installed.