2

We have some trouble with our web service client. The axis implementation we use was upgraded from version 1.3 to 1.4 and at the same time axis2 modules were introduced to the classpath. If you try to use the client to send a request now, the following error occurs:

Caused by: javax.xml.ws.soap.SOAPFaultException: java.lang.NullPointerException
at org.apache.axis2.jaxws.marshaller.impl.alt.MethodMarshallerUtils.createSystemException(MethodMarshallerUtils.java:1326)
at org.apache.axis2.jaxws.marshaller.impl.alt.MethodMarshallerUtils.demarshalFaultResponse(MethodMarshallerUtils.java:1052)
at org.apache.axis2.jaxws.marshaller.impl.alt.DocLitBareMethodMarshaller.demarshalFaultResponse(DocLitBareMethodMarshaller.java:415)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.getFaultResponse(JAXWSProxyHandler.java:577)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.createResponse(JAXWSProxyHandler.java:520)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:386)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:171)
at com.sun.proxy.$Proxy19.documentRepositoryProvideAndRegisterDocumentSetB(Unknown Source)

The same happens if we completely remove axis 1.4 from he classpath (which will probably not be possible in the release build as we have too many jars depending on it) and only use axis2. So this seems to be a problem with axis2. I tried to google anything but could not find a solution that matched our problem. Any ideas on what's going wrong here?

Viciouss
  • 283
  • 4
  • 20
  • Did you change the version of axis on the client, server, or both? Have you looked at the logs of the server? If I read your stack trace correctly, it appears that the message was sent and a response came back with a simple SOAP failure with message NullPointerException. Out of curiosity, axis2 is currently at version 1.6.2, why "upgrade" to 1.4? – Brett Okken Jun 10 '14 at 12:42
  • We only provide a client implementation. I added some information in the first post about the current state. For the upgrade, we have axis1 and axis2 in our classpath. With almost 900 jar files in total and various nasty dependencies in our code, it isn't always that easy to update from very old code to not that old code. We have to do it step by step to have the least impact, so we can actually fix what breaks before doing the next step. This has to be done while the software is running at the customer who needs updates by law. You can probably image how this could end. – Viciouss Jun 10 '14 at 15:08
  • Are you able to get any additional information from the service you are calling (i.e. log messages)? Are you able to use something like wireshark to identify exactly what message is going out on the wire? – Brett Okken Jun 10 '14 at 15:10
  • I'm sorry that it took so long for me to edit my post, I had to add some more information as I read the text again. – Viciouss Jun 10 '14 at 15:26
  • The response that you receive from the server is a SOAP Fault. Is that expected? Regarding the error, what is the exact version of Axis2 (1.4.? ) that you are using – AdityaKeyal Jun 12 '14 at 11:37
  • After some more research we found several things that were happening here. Please have a look at my answer to the question. I just edited everything to be more clear. – Viciouss Jun 12 '14 at 11:51

1 Answers1

0

As I'm quite new to web services, there are several lessons learned here:

  1. Although axis 1.4 is in our classpath, it is not used automatically as there is no Provider implementation. We used JAX-WS RI the whole time and didn't even notice. I just found this by inspecting the request with wireshark.

  2. The SOAPHandlers we created for our initial solution are responsible for the NPEs. I started debugging the whole thing and noticed that one of our handlers uses context.getMessage().getSOAPHeader() which returns null with axis2 although it returned the SOAPHeader while using the default implementation. The other is a workaround we added for multiple attachments (see https://java.net/jira/browse/WSIT-1320) which also fails because MTOM is now working as it should. What makes me wonder is, if there is an error in a handler, the framework builds up a SOAP error message containing the exception type (but not the actual stacktrace) of what just happened there and then goes on as usual. It returns this message and continues message parsing as if the message came as an answer to the request. From a developer perspective the stacktrace looks like the error was thrown on the server side or by some framework misuse, but the truth is that something went wrong in the handler and it threw an exception. This took quite a while to find out and is not really what I would expect.

  3. Never mix up different web service providers as it will always end in severe headaches. Communicate this with all the other departments in your company and do this as soon as possible before everything gets out of hand.

The big problem we face now is, we have an open source project that provides the web service client which is maintained by us. This project has no dependencies to any WS implementation as it uses the jax-ws ri implementation of Java. It is used in different environments right now, e.g. JBoss and an internal proprietary server environment. Until now there were no problems, although JBoss uses CXF and we have the mentioned default implementation, so they seem to be compatible. With the introduction of axis2 everything went wrong as the axis2-jaxws.jar has a service loader entry which is evaluated first and which can unfortunately not be overridden by the system property javax.xml.ws.spi.Provider. I tried removing this jar but it leads to other errors and I'm running out of ideas how we can actually fix the problem now.

I'll leave the thread open but right now I have little to no hope to get this fixed with the current setup.

Viciouss
  • 283
  • 4
  • 20