Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 76479 invoked from network); 17 Mar 2009 11:33:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Mar 2009 11:33:50 -0000 Received: (qmail 66809 invoked by uid 500); 17 Mar 2009 11:33:48 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 66745 invoked by uid 500); 17 Mar 2009 11:33:48 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 66736 invoked by uid 99); 17 Mar 2009 11:33:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2009 04:33:48 -0700 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of amilasuriarachchi@gmail.com designates 209.85.220.174 as permitted sender) Received: from [209.85.220.174] (HELO mail-fx0-f174.google.com) (209.85.220.174) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2009 11:33:41 +0000 Received: by fxm22 with SMTP id 22so1400770fxm.16 for ; Tue, 17 Mar 2009 04:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qR8ScMrkPxpZedNwu1Wi2tGSJ69BlexMy9suK07AcuA=; b=O3e+lLVDnMgH9GTmMtubAZROF92aS9/VBAesNwq3GNDyzxXBMh39/wsTS1iLPykbFE prK4vp+ZEIDuPw/Mgf3vOOK6sY1M1ziow9BocHWkxTKFp35WxfCbqf4Pa36wojtajY0Z evoZXlBAftKnnmABEt3niBiWAqWdEiPqCTgak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=otZCieHJSqEgRHWo9pTH9onlb9YKn4z/tsVMezVt1Wn8lKYeb9uHXBgwSSky7tDYvz u+NCpPEAjVuVlL2BeDjGc8yS+YMA2zxQsk0qGCHK9W5WEFSm1Rt3kvsNTvhK8E7UXw7D 4dAT4QCHooJsUAi/hPscoycSKixD15cX5xIn8= MIME-Version: 1.0 Received: by 10.103.198.15 with SMTP id a15mr2729454muq.60.1237289600194; Tue, 17 Mar 2009 04:33:20 -0700 (PDT) In-Reply-To: <3b3bfaf80903170322r6626e009t3b9625f5bfff6c73@mail.gmail.com> References: <3b3bfaf80903170322r6626e009t3b9625f5bfff6c73@mail.gmail.com> Date: Tue, 17 Mar 2009 17:03:20 +0530 Message-ID: <60708f4b0903170433g2e5b8335ge00ab30bf5a9ac2c@mail.gmail.com> Subject: Re: TransportListener and AxisEngine#sendFault(faultContext) tightly coupled From: Amila Suriarachchi To: axis-dev@ws.apache.org Content-Type: multipart/alternative; boundary=001636b431a41a993904654eef5a X-Virus-Checked: Checked by ClamAV on apache.org --001636b431a41a993904654eef5a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Mar 17, 2009 at 3:52 PM, Dobri Kitipov wrote: > Hi everyone, > I want to direct your attention to how OUT_FAULT_FLOW is triggered in > Axis2. > > 1) The short story > > When a request is received by the TransportListener (TL) (e.g. AxisServlet) > then it invokes the AxisEngine (i.e. AxisEngine#receive(msgContext)). If > there is a fault condition it is thrown by the engine and caught by the > TransportListener. What happens is that the whole logic about triggering the > OUT_FAULT_FLOW phases is placed into the TL, but not into the engine itself. > > You can refer to the AxisEngine#doPost() which in turn invokes its private > processAxisFault() when there is a fault condition. I also got the same feeling when I saw this code for the first time. > > > 2) The problem > > IMHO we can meet the following issue. If someone wants to create a custom > TL then it should have the "processAxisFault" logic implemented into it. > Since this is not well documented (I did not find a proper docu about this) > it come out that the TL is missing this logic need and will not work > properly. > > > 3) The proposal > > a) I did a short research and did not find any obstacle to include the the > "processAxisFault" logic into the engine itself (basically > AxisEngine#sendFault(faultContext) should be called). IMHO doing so the > architecture of Axis2 will be simplified and the fault logic will be > decoupled from the TL implementation. Of course some HttpServletResponse > processing should take place into the TL, but this is something more natural > to do ( ;) better known and/or understanded/documented). Did you have a time to look at how JMS, SMTP and other transport have implemented the Fault handling part. IMHO this code at least should go to transport base module so that all the transports can use it. > > > I think that this is worth having to be discussed. +1 thanks, Amila. > > > Please share your comments/opinions. > > Thank you in advance, > Dobri > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ --001636b431a41a993904654eef5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 17, 2009 at 3:52 PM, Dobri K= itipov <kdobrik.axis2@googlemail.com> wrote:
Hi everyone,
I want to direct your attention to how OUT_FAULT_FLOW is tr= iggered in Axis2.

1) The short story

When a request is recei= ved by the TransportListener (TL) (e.g. AxisServlet) then it invokes the Ax= isEngine (i.e. AxisEngine#receive(msgContext)). If there is a fault conditi= on it is thrown by the engine and caught by the TransportListener. What hap= pens is that the whole logic about triggering the OUT_FAULT_FLOW phases is = placed into the TL, but not into the engine itself.
You can refer to the AxisEngine#doPost() which in turn invokes its private = processAxisFault() when there is a fault condition.

I = also got the same=A0 feeling=A0 when I saw this code for the first time. =A0

=
2) The problem

IMHO we can meet the following issue. If someone = wants to create a custom TL then it should have the "processAxisFault&= quot; logic implemented into it. Since this is not well documented (I did n= ot find a proper docu about this) it come out that the TL is missing this l= ogic need and will not work properly.


3) The proposal

a) I did a short research and did not find a= ny obstacle to include the the "processAxisFault" logic into the engine itself (basically AxisEngine#sendFault(faultContext) should be called). IMHO doing so the architecture of Axis2 will be simplified and the fault logic will be decoupled from the TL implementation. Of course some HttpServletResponse pr= ocessing should take place into the TL, but this is something more natural = to do ( ;) better known and/or understanded/documented).

Did you have a time to look at how JMS, SMTP and other transport h= ave implemented the Fault handling part. IMHO this code at least should go = to transport base module so that all the transports can use it.


I think t= hat this is worth having to be discussed.
+1

thank= s,
Amila.
<= br>
Please share your comments/opinions.

Thank you in advance,
Dobri



--
Amila Suriarachc= hi
WSO2 Inc.
blog: ht= tp://amilachinthaka.blogspot.com/
--001636b431a41a993904654eef5a--