Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 35986 invoked from network); 27 Oct 2006 00:35:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Oct 2006 00:35:40 -0000 Received: (qmail 55965 invoked by uid 500); 27 Oct 2006 00:35:48 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 55918 invoked by uid 500); 27 Oct 2006 00:35: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 55893 invoked by uid 99); 27 Oct 2006 00:35:48 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Oct 2006 17:35:48 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [209.68.5.15] (HELO relay01.pair.com) (209.68.5.15) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 26 Oct 2006 17:35:36 -0700 Received: (qmail 84591 invoked by uid 0); 27 Oct 2006 00:35:13 -0000 Received: from unknown (HELO ?192.168.1.2?) (unknown) by unknown with SMTP; 27 Oct 2006 00:35:13 -0000 X-pair-Authenticated: 222.165.182.4 Subject: Re: Request for XML Filter (AXIS2-1085) From: Sanjiva Weerawarana To: axis-dev@ws.apache.org In-Reply-To: References: Content-Type: text/plain Organization: Lanka Software Foundation Date: Fri, 27 Oct 2006 06:04:26 +0530 Message-Id: <1161909266.9440.28.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Thu, 2006-10-26 at 08:34 -0500, R J Scheuerle Jr wrote: > > A uniquenes check requires the inspection of the entire message. > If a uniquess check is performed with a handler solution, there are > several undesirable outcomes: > 1) the OM tree will be traversed, which is expensive. > 2) the OM tree will be expanded and cached, which kills performance. > > If a uniquess check is performed with a filter and handler solution: > 1) The filter can inspect the StAX events as they are read. The filter > will not affect the caching of the OM tree. The filter will not pull > StAX events. > 2) The filter will store its results on the MessageContext. The second point is what's fundamentally inconsistent with Axis2's architecture. If you want to introduce a StAX filter that one's thing. But doing that and having access to the message context doesn't make sense: we create an OMElement for the envelope giving just the StAX stream and then create a message context using that envelope. If you want a StAX filter then it must be a StAX filter: StAX in, StAX out. I don't agree with the proposed change because its inconsistent with the design and appears to mix layers of processing. Sorry but unless there's more data on what this is I'm -1 on it. Eran/Ajith/Dims/Deepal/Bill/Glen/ etc., can you comment please? Am I missing something in this? Sanjiva. --------------------------------------------------------------------- To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org For additional commands, e-mail: axis-dev-help@ws.apache.org