0

I have generated POJO's from WSDL schema, but errors don't seem to be mapped to appropriate @Webfault exception. Instead of getting AXLError I receive ServerSOAPFaultException.

Generated exception file:

package com.cisco.axlapiservice;

import javax.xml.ws.WebFault;


/**
 * This class was generated by Apache CXF 3.1.8
 * 2016-11-13T14:30:37.692+02:00
 * Generated source version: 3.1.8
 */

@WebFault(name = "axlError", targetNamespace = "http://www.cisco.com/AXL/API/11.5")
public class AXLError extends Exception {

    private com.cisco.axl.api._11.AXLError axlError;

    public AXLError() {
        super();
    }

    public AXLError(String message) {
        super(message);
    }

    public AXLError(String message, Throwable cause) {
        super(message, cause);
    }

    public AXLError(String message, com.cisco.axl.api._11.AXLError axlError) {
        super(message);
        this.axlError = axlError;
    }

    public AXLError(String message, com.cisco.axl.api._11.AXLError axlError, Throwable cause) {
        super(message, cause);
        this.axlError = axlError;
    }

    public com.cisco.axl.api._11.AXLError getFaultInfo() {
        return this.axlError;
    }
}

Response returned from server:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Client</faultcode>
         <faultstring>Cannot insert or update pattern. A DN exists with the same pattern and partition.</faultstring>
         <detail>
            <axlError>
               <axlcode>4052</axlcode>
               <axlmessage>Cannot insert or update pattern. A DN exists with the same pattern and partition.</axlmessage>
               <request>addLine</request>
            </axlError>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

The following exception is thrown:

com.sun.xml.internal.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: Cannot insert or update pattern. A DN exists with the same pattern and partition. Please see the server log to find more detail regarding exact cause of the failure.
    at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
    at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:124)
    at com.sun.xml.internal.ws.client.sei.StubHandler.readResponse(StubHandler.java:238)
    at com.sun.xml.internal.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:189)
    at com.sun.xml.internal.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:276)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:104)
    at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77)
    at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147)
    at com.sun.proxy.$Proxy135.addLine(Unknown Source)
    at com.company.product.provisioning.AxlApi.addLine(AxlApi.java:243)
...

Could you please point me why I never receive an AXLError?

eugen-fried
  • 2,111
  • 3
  • 27
  • 48
  • 1
    This is CXF's standard way to map a `@WebFault`. If you try/catch a WebService method which receives a WebFault, it will raise a `AXLError` exception, which will contain the details of the fault in `com.cisco.axl.api._11.AXLError getFaultInfo()`. What is the problem? – pedrofb Nov 24 '16 at 07:53
  • Unfortunately it throws `ServerSOAPFaultException` instead of `AXLError`. – eugen-fried Nov 24 '16 at 08:20
  • It would be helpful if you post the stack trace – pedrofb Nov 24 '16 at 08:31
  • Added to the question – eugen-fried Nov 24 '16 at 08:41
  • I do not see the CXF classes being invoked in stack trace. Seems your client is using the internal implementation of JAX-WS included in JDK. I do not know if that can be the reason. With CXF client, the fault usually are well mapped – pedrofb Nov 24 '16 at 09:42
  • Indeed! I've added the maven plugin, but forgot to add the runtime dependencies. Please make a proper answer, so I could accept it. – eugen-fried Nov 24 '16 at 10:22

1 Answers1

2

This is CXF's standard way to map a @WebFault. If you try/catch a WebService method which receives a WebFault, it will raise a AXLError exception, which will contain the details of the fault in com.cisco.axl.api._11.AXLError getFaultInfo().

I do not see the CXF classes being invoked in stack trace. Seems your client is using the internal implementation of JAX-WS included in JDK. Perhaps you have forgotten to add the CXF jars to the runtime dependencies? If you use maven, you can add them to your classpath with the following snippet:

<properties>
    <cxf.version>3.1.8</cxf.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-rt-frontend-jaxws</artifactId>
        <version>${cxf.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-rt-transports-http</artifactId>
        <version>${cxf.version}</version>
    </dependency>
    <!-- Jetty is needed if you're are not using the CXFServlet -->
    <dependency>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-rt-transports-http-jetty</artifactId>
        <version>${cxf.version}</version>
    </dependency>
</dependencies>
eugen-fried
  • 2,111
  • 3
  • 27
  • 48
pedrofb
  • 37,271
  • 5
  • 94
  • 142