1 Reply Latest reply on Oct 9, 2007 4:26 AM by Richard Opalka

    WSSecurity failure on Linux

    Peter Johnson Master

      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.




        • 1. Re: WSSecurity failure on Linux
          Richard Opalka Newbie

          Hi PeterJ,

          thank you for your investigation. I reviewed your post and our batch files and you are right, the classpath elements order is different for windows and different for linux. So I applied your suggestion to our distribution.
          This fix should be available in the next release (JBossWS 2.0.2) at the end of October.

          Richard