Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 36908 invoked from network); 9 Nov 2006 17:20:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Nov 2006 17:20:37 -0000 Received: (qmail 61934 invoked by uid 500); 9 Nov 2006 17:20:40 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 61898 invoked by uid 500); 9 Nov 2006 17:20:40 -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 61884 invoked by uid 99); 9 Nov 2006 17:20:40 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Nov 2006 09:20:40 -0800 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=DNS_FROM_RFC_POST,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [203.141.92.57] (HELO eagle.sagamino.jp.ibm.com) (203.141.92.57) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Nov 2006 09:20:24 -0800 Received: from e19p2l2.sagamino.japan.ibm.com (d19relay12.sagamino.japan.ibm.com [203.141.92.43]) by eagle.sagamino.jp.ibm.com (8.12.11.20060614/8.12.11) with ESMTP id kA9HK2ni061776 for ; Fri, 10 Nov 2006 02:20:02 +0900 Received: from d19av02.sagamino.japan.ibm.com (d19av02.sagamino.japan.ibm.com [9.189.5.91]) by e19p2l2.sagamino.japan.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA9HK2b6856066 for ; Fri, 10 Nov 2006 02:20:02 +0900 Received: from d19av02.sagamino.japan.ibm.com (loopback [127.0.0.1]) by d19av02.sagamino.japan.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA9HK1VS021198 for ; Fri, 10 Nov 2006 02:20:01 +0900 Received: from d19ml118.sagamino.japan.ibm.com (d19ml118.sagamino.japan.ibm.com [9.189.4.81]) by d19av02.sagamino.japan.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA9HK1l5017898 for ; Fri, 10 Nov 2006 02:20:01 +0900 In-Reply-To: To: axis-dev@ws.apache.org MIME-Version: 1.0 Subject: Re: Request for XML Filter (AXIS2-1085) X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Takahide Nogayama Message-ID: Date: Fri, 10 Nov 2006 02:19:19 +0900 X-MIMETrack: Serialize by Router on D19ML118/19/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 2006/11/10 02:20:01, Serialize complete at 2006/11/10 02:20:01 Content-Type: multipart/alternative; boundary="=_alternative 005F268449257221_=" X-Virus-Checked: Checked by ClamAV on apache.org --=_alternative 005F268449257221_= Content-Type: text/plain; charset="US-ASCII" All, I inspect the Handler solution, the following is pros and cons. pros) There is no layer mixing. pros) There are no filter related code in AXIS2. cons) Need to change StAXBuilder to replace XMLStreamReader by Filter. To replace XMLStreamReader of builder by Filter, we have to add "setParser" method to "StAXBuilder". (we can get builder instance in handler by using ((OMElementImpl)msgctx.getEnvelope()).getBuilder() ) Apache community had already disscussed about this method ever. They concluded that they will never add this method to StAXBuilder. Because if some one tries to changes the parser, while the object model is being built or partially build, everything will get screwed. I heard this from Eran.http://issues.apache.org/jira/browse/WSCOMMONS-76#action_12434318 cons) Filter can not see SOAPHeader StAXEvents. SOAPHeader part is probably already built at the time by SOAPEnvelope.getBody(). For Example, (if we can add setParser to StAXBuilder) WSS specification says that two wsu:Id attributes within an XML document MUST NOT have the same value. So Id-Uniqueness-check-Filter must check Id-Uniqueness against entire XML document. However, at the top of Handler chain, the elements before have already been build by SOAPEnvelope.getBody(). That is, its StAX events are consumed and trashed. Id-Uniqueness-check-Filter which is inserted by handler can check the StAX events of and its descendant elements, but it can not check entire Id-Uniqueness. --------------------------- Takahide Nogayama --=_alternative 005F268449257221_= Content-Type: text/html; charset="US-ASCII"
All,

I inspect the Handler solution, the following is pros and cons.

    pros) There is no layer mixing.
    pros) There are no filter related code in AXIS2.
   
    cons) Need to change StAXBuilder to replace XMLStreamReader by Filter.
        To replace XMLStreamReader of builder by Filter, we have to add "setParser" method to "StAXBuilder".
        (we can get builder instance in handler by using ((OMElementImpl)msgctx.getEnvelope()).getBuilder() )
        Apache community had already disscussed about this method ever. They concluded that they will never
        add this method to StAXBuilder. Because if some one tries to changes the parser, while the object
        model is being built or partially build, everything will get screwed.
        I heard this from Eran.http://issues.apache.org/jira/browse/WSCOMMONS-76#action_12434318

    cons) Filter can not see SOAPHeader StAXEvents. SOAPHeader part is probably already built at the time by SOAPEnvelope.getBody().
        For Example, (if we can add setParser to StAXBuilder) WSS specification says that two wsu:Id attributes within
        an XML document MUST NOT have the same value. So Id-Uniqueness-check-Filter must check Id-Uniqueness against entire XML
        document. However, at the top of Handler chain, the elements before <soapenv:Body> have already been build by
        SOAPEnvelope.getBody(). That is, its StAX events are consumed and trashed. Id-Uniqueness-check-Filter which is inserted by handler
        can check the StAX events of <soapenv:Body> and its descendant elements, but it can not check entire Id-Uniqueness.

---------------------------
Takahide Nogayama
--=_alternative 005F268449257221_=--