Mailing-List: contact cxf-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Message-ID: <11579124.1193321931107.JavaMail.jira@brutus>
Date: Thu, 25 Oct 2007 07:18:51 -0700 (PDT)
From: "Glen Mazza (JIRA)" <jira@apache.org>
To: cxf-issues@incubator.apache.org
Subject: [jira] Commented: (CXF-1136) Custom exception not appearing in SOAP
 fault response
In-Reply-To: <28711152.1193307770662.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537610 ] 

Glen Mazza commented on CXF-1136:
---------------------------------

In comparing Metro and CXF outputs, I think I found the problem.  You appear to be using a nonstandard form of creating an exception that does *not* result in the underlying CustomException exception being stored.  I do not know why CXF provides this form.

In your service class, you call:
    throw new CustomException("custom error");

In other words, the first of these three possible constructors:

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

    public CustomException (String message, demo.hw.company.CustomExceptionType customException) {
        super(message); this.customException = customException;  }

    public CustomException (String message, demo.hw.company.CustomExceptionType customException, Throwable cause) {
        super(message, cause);  this.customException = customException;  }

But only the latter two causes the customException to be stored.  

Metro's wsimport, at least JAX-WS 2.1 version, does *not* provide for the top constructor that you were unwittingly using, so you must use either of the bottom two.  I don't know enough about why we provide the first constructor variant--either it's a JAX-WS 2.0 construct or a good intention that may not be that helpful after all.  (Team:  should we get rid of the first constructor variant?  Is this even called for in JAX-WS?)

At any rate, if you look at how I constructed EntryAlreadyExistsFault in function addWordEntry() in [1] below, you'll see how you can create your exceptions so that they can be trapped on the client side.

HTH,
Glen

[1] http://www.jroller.com/gmazza/date/20071019#step6


> Custom exception not appearing in SOAP fault response
> -----------------------------------------------------
>
>                 Key: CXF-1136
>                 URL: https://issues.apache.org/jira/browse/CXF-1136
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.0.2
>         Environment: WIndows XP
> Java SDK 1.5_0_12
>            Reporter: ed p
>            Priority: Critical
>         Attachments: helloWorld.wsdl, java_first_jaxws.zip
>
>
> I modified the apache-cxf-2.0.2-incubator\samples\java_first_jaxws web service to throw a custom exception and a custom request and response object like so:
> public interface HelloWorld {
>     Response sayHi(Request text) throws CustomException;
> }
> CustomException is a CustomExceptionBase with two string properties. CustomExceptionBase is a java.lang.Exception
> The CustomException appears in the WSDL but the CustomExceptionBase is missing. When the service is invoked and throws a CustomException the soap response is:
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>    <soap:Body>
>       <soap:Fault>
>          <faultcode>soap:Server</faultcode>
>          <faultstring>custom error</faultstring>
>       </soap:Fault>
>    </soap:Body>
> </soap:Envelope>
> I am expecting to see the CustomException serialized in the Envelope/Body/Fault/detail node.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.