Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <465278129.1253646976229.JavaMail.jira@brutus>
Date: Tue, 22 Sep 2009 12:16:16 -0700 (PDT)
From: "Dino (JIRA)" <jira@apache.org>
To: axis-dev@ws.apache.org
Subject: [jira] Commented: (AXIS2-4280) Handle error handling of AxisFault
 better
In-Reply-To: <597447382.1237661450697.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AXIS2-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758378#action_12758378 ] 

Dino commented on AXIS2-4280:
-----------------------------

I would just remove the log.error(e.getMessage()). I don't think you need a real patch for that.

It is not good coding practice to log an error and propagate the exception since it can be treated by the client code in a specific manner.

This is especially true of faults since it is part of the contract of the web service call.

> Handle error handling of AxisFault better
> -----------------------------------------
>
>                 Key: AXIS2-4280
>                 URL: https://issues.apache.org/jira/browse/AXIS2-4280
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 1.4.1
>         Environment: NA
>            Reporter: Dino
>            Priority: Critical
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Every time I throw an application fault the error gets displayed in server side as an error.
> To reproduce: run the faulthandling example from the distribution (xis2-1.4.1/samples/faulthandling)
> In the server side you get:
> ERROR] Account does not exist!
> org.apache.axis2.AxisFault: Account does not exist!
>     at example.BankServiceMessageReceiverInOut.createAxisFault(BankServiceMessageReceiverInOut.java:237)
>     at example.BankServiceMessageReceiverInOut.invokeBusinessLogic(BankServiceMessageReceiverInOut.java:75)
>     at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
>     at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:100)
>     at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:176)
>     at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>     at org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:278)
>     at org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281)
>     at org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187)
>     at org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82)
>     at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
>     at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
>     at java.lang.Thread.run(Thread.java:613)
> I tracked the source of the error and it is in class AxisEngine line 212 where it blindly logs all faults as errors:
> catch (AxisFault e) {
>             log.error(e.getMessage(), e);  // <<<<<
>             msgContext.setFailureReason(e);
>             flowComplete(msgContext);
>             throw e;
>         }
> Now, the only way to deal with it now is to switch off logging which is never a good idea. This is a serious bad issue if you want to use faults. 

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