I have just spent the better part of a day trying to figure out why my Web service, which uses WSSecurity to either encrypt or sign my messages, works on Windows but not on Linux. What really bugged my is that no matter whether I built the Web service and client on Windows or on Linux, the resulting JARs would work on Windows but not Linux. In other words, I could build on Linux, and those JARs failed on Linux but worked on Windows. And vice-versa.
The error? Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: org.jboss.ws.core.CommonSOAPFaultException: This service requires <wsse:Security>, which is missing. | at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.getSOAPFaultException(SOAPFaultHelperJAXWS.java:69) | at org.jboss.ws.core.jaxws.binding.SOAP11BindingJAXWS.throwFaultException(SOAP11BindingJAXWS.java:109) | at org.jboss.ws.core.CommonSOAPBinding.unbindResponseMessage(CommonSOAPBinding.java:553) | at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:371) | at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:243) | at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:164) | at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:150) Then inspiration struck. While attempting to debug the situation, I noticed that log4j correctly picked up its configuration file on Windows, but not on Linux. Apparently on Windows, the client's JAR files are placed first in the classpath, but on Linux they are placed last. Which caused a stray log4j configuration file to be used on Linux. (And yes, I did remove the "-Dlog4j.configuration=wstools-log4j.xml" option from the command line in wsrunclient. Not sure who thought it was a good idea to prevent users from defining their own log4j configuration files.) Anyway, I changes the order in which the classpath was built, moving the following code in wsrunclient.sh: while [ $# -ge 1 ]; do | case $1 in | "-classpath") WSRUNCLIENT_CLASSPATH="$WSRUNCLIENT_CLASSPATH:$2"; shift;; | *) args="$args \"$1\"";; | esac | shift | done before these lines: # Setup the client classpath | WSRUNCLIENT_CLASSPATH="$WSRUNCLIENT_CLASSPATH:$JBOSS_HOME/client/log4j.jar" | WSRUNCLIENT_CLASSPATH="$WSRUNCLIENT_CLASSPATH:$JBOSS_HOME/client/jbossws-client.jar" The Web service now works correctly on Linux. Any possibility that the wsrunclient.sh could be permanently fixed? What I was running: JBoss 5.0.0 beta3 pulled on Sept 27, which appears to contain jbossws-native-2.0.1.SP1 I checked JBossWS 2.0.0.GA and 2.0.1.GA, and both of their wsrunclient.sh files have the same problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092751#4092751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092751 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
