From ydavis@example.org Sat May 01 07:13:43 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 76647 invoked from network); 1 May 2010 07:13:42 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 1 May 2010 07:13:42 -0000 Received: (qmail 21144 invoked by uid 500); 1 May 2010 07:13:42 -0000 Delivered-To: ydavis@example.org Received: (qmail 20775 invoked by uid 500); 1 May 2010 07:13:41 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 20755 invoked by uid 99); 1 May 2010 07:13:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 May 2010 07:13:41 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO sosnoski.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 May 2010 07:13:32 +0000 Received: from [83.161.120.155] (ip-409-564-7709.static-xdsl.xnet.co.nz [83.161.120.155]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id o417CZno028679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 May 2010 03:12:39 -0400 Message-ID: <ydavis@example.org> Date: Sat, 01 May 2010 19:12:29 +1200 From: Dennis Sosnoski <ydavis@example.org> User-Agent: Thunderbird 83.161.120.155 (X11/20090822) MIME-Version: 1.0 To: ydavis@example.org CC: Amila Suriarachchi <ydavis@example.org>, ydavis@example.org, ydavis@example.org Subject: Re: Performance Comparison References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Yes, I think it'd make much more sense to base a build-on-demand document model on the DOM API than to try to modify all the WSS4J and related code to use Axiom. Especially since Axiom is a mess and has had performance issues from the beginning (including using way too much memory as the model is expanded). As a radical suggestion, how about just implementing a build-on-demand DOM subset suitable for use by WSS4J and other tools? This wouldn't need to support all the DOM operations (including those using NodeList). Daniel Kulp wrote: > > The "normal" way to traverse a DOM doesn't use the NodeList thing. The > NodeList stuff isn't even threadsafe in Xerces. Actually, *no* access operations are threadsafe in Xerces. As far as I'm concerned that's a really bad design for general purpose use, ironically going back to the deferred node expansion feature that Xerces has on by default. It's always irked me that I have to use a synchronization lock around read-only operations with a (Xerces) DOM. That said, any form of build-on-demand document model is probably not going to be threadsafe. But for our purposes in using it with web services there's not much need for threadsafety. - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Sun May 02 21:38:42 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 94718 invoked from network); 2 May 2010 21:38:40 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 2 May 2010 21:38:40 -0000 Received: (qmail 16289 invoked by uid 500); 2 May 2010 21:38:39 -0000 Delivered-To: ydavis@example.org Received: (qmail 15914 invoked by uid 500); 2 May 2010 21:38:39 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 15370 invoked by uid 99); 2 May 2010 21:38:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 May 2010 21:38:38 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO fg-out-1718.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 May 2010 21:38:31 +0000 Received: by fg-out-1718.google.com with SMTP id 19so507147fgg.16 for <multiple recipients>; Sun, 02 May 2010 14:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=VRdn8EqEQTv3SdrEkGDqyucXLvyEQWZfn9irZjMeOk4=; b=ACPMOs4ARYJxrI3B6gn8wq0d3KCCvl25IlA4jPoTK34/0FgXRgjlhLpTv9JcAZZXmd RtpbM8chSgEpLT8QQNYlu3L4I/DupAO7FUYouKYYOVux2y7RQSSBnk6wVtLwqpmPWogn l0W2hTitHGAaWJy6LJeykZ69yuLNKCPLaEZW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PcYGGB2tZrc8hAXTHANVFfNYEJBYJp3NfDx9p6wg5GwSHNn3gyxqAm4rHpVoRGdZMV vhKLmFZQBg7P2RRTmhXBeWiqZ+8M50xYkdo5LghxX5RBZyYfjLcF4FLaNX3W6+WOmWqM DDmh7Ir+iYyCVZqtuFfZAJABoLmTWE+J3K7tI= Received: by 83.161.120.155 with SMTP id 19mr1361543hbo.63.1272836291112; Sun, 02 May 2010 14:38:11 -0700 (PDT) MIME-Version: 1.0 Received: by 83.161.120.155 with HTTP; Sun, 2 May 2010 14:37:51 -0700 (PDT) In-Reply-To: <ydavis@example.org> References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> From: Andreas Veithen <ydavis@example.org> Date: Sun, 2 May 2010 23:37:51 +0200 Message-ID: <ydavis@example.org> Subject: Re: Performance Comparison To: ydavis@example.org Cc: ydavis@example.org, Amila Suriarachchi <ydavis@example.org>, ydavis@example.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <ydavis@example.org> wrote: > Yes, I think it'd make much more sense to base a build-on-demand document > model on the DOM API than to try to modify all the WSS4J and related code= to > use Axiom. Especially since Axiom is a mess and has had performance issue= s > from the beginning (including using way too much memory as the model is > expanded). Each of the two approaches (porting WSS4J to Axiom / building a new optimized Axiom+DOM implementation) have their pros and cons and I think there is enough room for the two. They could even be complementary provided that the new Axiom+DOM implementation has a lower memory footprint and better performance. > As a radical suggestion, how about just implementing a build-on-demand DO= M > subset suitable for use by WSS4J and other tools? This wouldn't need to > support all the DOM operations (including those using NodeList). That part is actually almost ready [1] (with more than just a subset suitable for WSS4J). However, to work with Axis2 we have no other choice than to support the Axiom API as well, at least the object model part of it (while getting rid of what you called the "mess"). [1] http://code.google.com/p/ddom/ > Daniel Kulp wrote: >> >> The "normal" way to traverse a DOM doesn't use the NodeList thing. =A0 T= he >> NodeList stuff isn't even threadsafe in Xerces. > > Actually, *no* access operations are threadsafe in Xerces. As far as I'm > concerned that's a really bad design for general purpose use, ironically > going back to the deferred node expansion feature that Xerces has on by > default. It's always irked me that I have to use a synchronization lock > around read-only operations with a (Xerces) DOM. > > That said, any form of build-on-demand document model is probably not goi= ng > to be threadsafe. But for our purposes in using it with web services ther= e's > not much need for threadsafety. > > =A0- Dennis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ydavis@example.org > For additional commands, e-mail: ydavis@example.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Mon May 03 05:04:04 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 66374 invoked from network); 3 May 2010 05:04:04 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 3 May 2010 05:04:04 -0000 Received: (qmail 62560 invoked by uid 500); 3 May 2010 05:04:04 -0000 Delivered-To: ydavis@example.org Received: (qmail 62160 invoked by uid 500); 3 May 2010 05:04:02 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 62142 invoked by uid 99); 3 May 2010 05:04:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 05:04:01 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=10.0 tests=AWL,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO sosnoski.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 05:03:55 +0000 Received: from [83.161.120.155] (ip-409-564-7709.static-xdsl.xnet.co.nz [83.161.120.155]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id o4352vno007639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 01:03:02 -0400 Message-ID: <ydavis@example.org> Date: Mon, 03 May 2010 17:02:51 +1200 From: Dennis Sosnoski <ydavis@example.org> User-Agent: Thunderbird 83.161.120.155 (X11/20090822) MIME-Version: 1.0 To: Andreas Veithen <ydavis@example.org> CC: ydavis@example.org, ydavis@example.org, Amila Suriarachchi <ydavis@example.org>, ydavis@example.org Subject: Re: Performance Comparison References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andreas Veithen wrote: > On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <ydavis@example.org> wrote: > >> ... >> > > Each of the two approaches (porting WSS4J to Axiom / building a new > optimized Axiom+DOM implementation) have their pros and cons and I > think there is enough room for the two. They could even be > complementary provided that the new Axiom+DOM implementation has a > lower memory footprint and better performance. > > >> As a radical suggestion, how about just implementing a build-on-demand DOM >> subset suitable for use by WSS4J and other tools? This wouldn't need to >> support all the DOM operations (including those using NodeList). >> > > That part is actually almost ready [1] (with more than just a subset > suitable for WSS4J). However, to work with Axis2 we have no other > choice than to support the Axiom API as well, at least the object > model part of it (while getting rid of what you called the "mess"). > > [1] http://code.google.com/p/ddom/ > Well, I suspect most people who've looked into the Axiom code and tried to follow the spaghetti paths involved in building the nodes would agree with the "mess" characterization. :-) This is not to say that the code is necessarily poorly written, either - it's just a very complex process to try to build a DOM incrementally, as the Axiom developers have found. Your DDOM project looks like an interesting 2nd-generation take on Axiom, and as such it should definitely represent a major improvement. After thinking it over and seeing how deferred building is actually applied with web services, though, I wonder if a simpler approach wouldn't be better. On the inbound side it's pretty easy to implement deferred building, since all the current-generation web services stacks use pull parsing. If you need to build a DOM, you just use the pull parser to do so and supply a pull parser facade for reading data back out of the DOM, and all the rest of the code just works with the pull parser. The outbound side is more difficult. ADB implements a StAX reader for pulling data out of data bound objects, but other data bindings such as JiBX and JAXB do not. This means that if you want to build a DOM for any portion of the bound data you pretty much need to do the whole thing, since these data bindings use push output. But that's actually not such a drawback, since it corresponds with the way WS-* uses the data in the document - if you need a DOM representation for *any* of the data in the SOAP Body, you probably need it for *all* the data. It doesn't have to be that way, but in practice, how often do you see WS-Security, for instance, applied to only a portion of the SOAP Body? So rather than an incremental build-on-demand model, I think an approach which just flipped DOM on or off at the message level would work just as well for web services. On the inbound side, if a SOAP Header is present you'd just always build a DOM representation of the Header part so it can be passed to handlers in an easily-manipulated form. If any of the handlers request the content of the SOAP Body you'd then build that as a DOM and pass it in. Outbound side is pretty much the same, with the data only requested from the data binding if needed to build the DOM and otherwise streamed directly to the output. Using this approach there's no need to build the DOM incrementally, other than at this very granular Header/Body level, so all that's required is a simple and high-performance DOM (or DOM subset) with just enough built-in smarts to recognize the Body expansion part, along with a StAX reader which takes a DOM as input. - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Mon May 03 07:21:58 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 88070 invoked from network); 3 May 2010 07:21:58 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 3 May 2010 07:21:58 -0000 Received: (qmail 34923 invoked by uid 500); 3 May 2010 07:21:58 -0000 Delivered-To: ydavis@example.org Received: (qmail 34536 invoked by uid 500); 3 May 2010 07:21:55 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 34520 invoked by uid 99); 3 May 2010 07:21:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 07:21:55 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO sosnoski.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 07:21:46 +0000 Received: from [83.161.120.155] (ip-409-564-7709.static-xdsl.xnet.co.nz [83.161.120.155]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id o437Kmno008284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 03:20:53 -0400 Message-ID: <ydavis@example.org> Date: Mon, 03 May 2010 19:20:36 +1200 From: Dennis Sosnoski <ydavis@example.org> User-Agent: Thunderbird 83.161.120.155 (X11/20090822) MIME-Version: 1.0 To: Andreas Veithen <ydavis@example.org> CC: ydavis@example.org, ydavis@example.org, Amila Suriarachchi <ydavis@example.org>, ydavis@example.org Subject: Re: Performance Comparison References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Whoops, meant to have this in my first response... Andreas Veithen wrote: > Each of the two approaches (porting WSS4J to Axiom / building a new > optimized Axiom+DOM implementation) have their pros and cons and I > think there is enough room for the two. They could even be > complementary provided that the new Axiom+DOM implementation has a > lower memory footprint and better performance. > I can't really see much of a pro in porting WSS4J to Axiom. This would mean either forking the code, with the associated maintenance issues, or deliberately choosing to lower WSS4J's performance with other applications just so that Axis2 improves (and creating an Axiom dependency for everyone else using WSS4J). Implementing a DOM interface usable by WSS4J on top of a modified Axiom seems like a better choice, so that Axis2 can avoid unnecessary conversions and boost its performance without hurting other users of WSS4J. Or instead using a simpler version of build-on-demand than that implemented by Axiom, as discussed in the earlier reply. - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Mon May 03 10:35:02 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 13821 invoked from network); 3 May 2010 10:34:59 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 3 May 2010 10:34:59 -0000 Received: (qmail 75111 invoked by uid 500); 3 May 2010 10:34:58 -0000 Delivered-To: ydavis@example.org Received: (qmail 74235 invoked by uid 500); 3 May 2010 10:34:55 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 74214 invoked by uid 99); 3 May 2010 10:34:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 10:34:53 +0000 X-ASF-Spam-Status: No, hits=-0.6 required=10.0 tests=AWL,FREEMAIL_FROM,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-fx0-f49.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 10:34:48 +0000 Received: by fxm17 with SMTP id 17so1976688fxm.22 for <multiple recipients>; Mon, 03 May 2010 03:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=SPU4uyy8UHz5OroT+x9AyTn4lcOyqZuU+2T/+onzelM=; b=Bt3RF3UlQbRRh2Z3qPOJMeuqGAtXGSmz5OWkQQxqRRSbaPDKlOhY1W6bU6HmLOlOYr sWOpXOLdFngwvvPQKAeVgAl57mhUSOfETLHHXg20bU4wGIwbv+88yEcCBeWLRzcCfxff VE8GtostbGr8m3fgC7nsMsUywd9GqyFPfJn2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=xKxAuo1oYW34n3nzleWYe0WRo0/xazQNuzk/SuuIWqkykEG13ndCkSxmOYE5tw0RQc a+HLNpf2lsiGXgIPxviX88t8SxbC+OMwAnrRBOA35lsgkWDkpDnbcGtsPQk8hcZ2H74H JXkJ3RiZIcTrE6vyui+GO5/4krxlxCDOG08vY= Received: by 83.161.120.155 with SMTP id t6mr248657hbd.204.1272882866135; Mon, 03 May 2010 03:34:26 -0700 (PDT) MIME-Version: 1.0 Received: by 83.161.120.155 with HTTP; Mon, 3 May 2010 03:34:06 -0700 (PDT) In-Reply-To: <ydavis@example.org> References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> From: Andreas Veithen <ydavis@example.org> Date: Mon, 3 May 2010 12:34:06 +0200 Message-ID: <ydavis@example.org> Subject: Re: Performance Comparison To: Dennis Sosnoski <ydavis@example.org> Cc: ydavis@example.org, ydavis@example.org, Amila Suriarachchi <ydavis@example.org>, ydavis@example.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <ydavis@example.org> wrote: > Andreas Veithen wrote: >> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <ydavis@example.org> wrote: >> >>> >>> ... >>> >> >> Each of the two approaches (porting WSS4J to Axiom / building a new >> optimized Axiom+DOM implementation) have their pros and cons and I >> think there is enough room for the two. They could even be >> complementary provided that the new Axiom+DOM implementation has a >> lower memory footprint and better performance. >> >> >>> >>> As a radical suggestion, how about just implementing a build-on-demand >>> DOM >>> subset suitable for use by WSS4J and other tools? This wouldn't need to >>> support all the DOM operations (including those using NodeList). >>> >> >> That part is actually almost ready [1] (with more than just a subset >> suitable for WSS4J). However, to work with Axis2 we have no other >> choice than to support the Axiom API as well, at least the object >> model part of it (while getting rid of what you called the "mess"). >> >> [1] http://code.google.com/p/ddom/ >> > > Well, I suspect most people who've looked into the Axiom code and tried t= o > follow the spaghetti paths involved in building the nodes would agree wit= h > the "mess" characterization. :-) =A0This is not to say that the code is > necessarily poorly written, either - it's just a very complex process to = try > to build a DOM incrementally, as the Axiom developers have found. > > Your DDOM project looks like an interesting 2nd-generation take on Axiom, > and as such it should definitely represent a major improvement. After > thinking it over and seeing how deferred building is actually applied wit= h > web services, though, I wonder if a simpler approach wouldn't be better. > > On the inbound side it's pretty easy to implement deferred building, sinc= e > all the current-generation web services stacks use pull parsing. If you n= eed > to build a DOM, you just use the pull parser to do so and supply a pull > parser facade for reading data back out of the DOM, and all the rest of t= he > code just works with the pull parser. The outbound side is more difficult= . > ADB implements a StAX reader for pulling data out of data bound objects, = but > other data bindings such as JiBX and JAXB do not. This means that if you > want to build a DOM for any portion of the bound data you pretty much nee= d > to do the whole thing, since these data bindings use push output. Note that ADB (neither POJOs nor generated code) no longer provides (a working) pull parser and always uses push, as the other data bindings. This is BTW an issue in some cases: http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102 > But that's actually not such a drawback, since it corresponds with the wa= y > WS-* uses the data in the document - if you need a DOM representation for > *any* of the data in the SOAP Body, you probably need it for *all* the da= ta. > It doesn't have to be that way, but in practice, how often do you see > WS-Security, for instance, applied to only a portion of the SOAP Body? > > So rather than an incremental build-on-demand model, I think an approach > which just flipped DOM on or off at the message level would work just as > well for web services. On the inbound side, if a SOAP Header is present > you'd just always build a DOM representation of the Header part so it can= be > passed to handlers in an easily-manipulated form. If any of the handlers > request the content of the SOAP Body you'd then build that as a DOM and p= ass > it in. Outbound side is pretty much the same, with the data only requeste= d > from the data binding if needed to build the DOM and otherwise streamed > directly to the output. Using this approach there's no need to build the = DOM > incrementally, other than at this very granular Header/Body level, so all > that's required is a simple and high-performance DOM (or DOM subset) with > just enough built-in smarts to recognize the Body expansion part, along w= ith > a StAX reader which takes a DOM as input. Sounds pretty much like CXF... > > =A0- Dennis > --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Mon May 03 10:48:58 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 15696 invoked from network); 3 May 2010 10:48:58 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 3 May 2010 10:48:58 -0000 Received: (qmail 87492 invoked by uid 500); 3 May 2010 10:48:58 -0000 Delivered-To: ydavis@example.org Received: (qmail 87229 invoked by uid 500); 3 May 2010 10:48:56 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 87207 invoked by uid 99); 3 May 2010 10:48:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 10:48:55 +0000 X-ASF-Spam-Status: No, hits=-0.6 required=10.0 tests=AWL,FREEMAIL_FROM,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-fx0-f49.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 10:48:49 +0000 Received: by fxm17 with SMTP id 17so1985881fxm.22 for <multiple recipients>; Mon, 03 May 2010 03:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=OxpSxIl9a2vvZETzZlxiY27iOoOSsKCenV1dAi2+I8c=; b=igKsflUd2LrFi1qsvIdZ9Oqftcx7lV/+mdagW+9bdK1YoPaTitNzerBRIChRLKLvhE NUHYbKfVBG2+iTuBzgUh1+nn+1J5EYWLzOD5awYwoZVHldoFW8dQ6RLG0faxg8WTORSh /KOh2toYqZlTtwX3HhoE0dNT9JL7XgwHKKuf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Qf/U5srGwEgUGCD0m1fPcvGMfT2vtiY1XcE68FlN0IoWgjs2R855nnmLH0MnSp8HHj PB7BovM9Mo8CF2NguTRS3EXLRTtDfz1YydFzMOFHACc+T/KDqA8QrfYFAeCpLG+OQSPN XVIwkLESk9RbUEFViVXZec5NSSqzvP/vEfSec= Received: by 83.161.120.155 with SMTP id v15mr1426787hbc.101.1272883708212; Mon, 03 May 2010 03:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 83.161.120.155 with HTTP; Mon, 3 May 2010 03:48:08 -0700 (PDT) In-Reply-To: <ydavis@example.org> References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> From: Andreas Veithen <ydavis@example.org> Date: Mon, 3 May 2010 12:48:08 +0200 Message-ID: <ydavis@example.org> Subject: Re: Performance Comparison To: Amila Suriarachchi <ydavis@example.org> Cc: Dennis Sosnoski <ydavis@example.org>, ydavis@example.org, ydavis@example.org, ydavis@example.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 3, 2010 at 10:19, Amila Suriarachchi <ydavis@example.org> wrote: > Is (or was) there any reason to Axiom to come up with an new API rather t= han > using DOM API? I guess that one of the goals was also to provide an API that is more convenient than DOM. > I was thinking that Dom does not support differed building and that seems= to > be wrong. It is possible to do deferred parsing/building with DOM, but one needs to write the code carefully (e.g. to avoid using the NodeList interface to iterate over the children of a node). That is probably another reason for choosing an entirely different API; indeed the Axiom API more or less forces you to write your code in such a way that it doesn't build nodes "accidentally". > There are some axis2 specific methods to get under line xml stream etc... > But they would have added by > extending the DOM API. It would indeed have been possible to build Axiom by extending the DOM API, but that is actually not so straightforward as it seems. That for example DOM's Node#getFirstChild method. That method returns a reference of type org.w3c.dom.Node. So either you need to add a new method with the extended interface as return type, or the caller needs to cast the return value to that extended interface. The first approach would pretty much result in something that looks like Axiom+DOM (DOOM), the second approach would have been simpler for Axiom but less convenient for Axis2 (or any other code using Axiom). > thanks, > Amila. > > > On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <ydavis@example.org> wrote= : >> >> Whoops, meant to have this in my first response... >> >> Andreas Veithen wrote: >>> >>> Each of the two approaches (porting WSS4J to Axiom / building a new >>> optimized Axiom+DOM implementation) have their pros and cons and I >>> think there is enough room for the two. They could even be >>> complementary provided that the new Axiom+DOM implementation has a >>> lower memory footprint and better performance. >>> >> >> I can't really see much of a pro in porting WSS4J to Axiom. This would >> mean either forking the code, with the associated maintenance issues, or >> deliberately choosing to lower WSS4J's performance with other applicatio= ns >> just so that Axis2 improves (and creating an Axiom dependency for everyo= ne >> else using WSS4J). >> >> Implementing a DOM interface usable by WSS4J on top of a modified Axiom >> seems like a better choice, so that Axis2 can avoid unnecessary conversi= ons >> and boost its performance without hurting other users of WSS4J. Or inste= ad >> using a simpler version of build-on-demand than that implemented by Axio= m, >> as discussed in the earlier reply. >> >> =A0- Dennis >> >> > > > > -- > Amila Suriarachchi > WSO2 Inc. > blog: http://amilachinthaka.blogspot.com/ > --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Mon May 03 10:58:38 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 19256 invoked from network); 3 May 2010 10:58:37 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 3 May 2010 10:58:37 -0000 Received: (qmail 95874 invoked by uid 500); 3 May 2010 10:58:37 -0000 Delivered-To: ydavis@example.org Received: (qmail 95496 invoked by uid 500); 3 May 2010 10:58:35 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 95473 invoked by uid 99); 3 May 2010 10:58:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 10:58:34 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=10.0 tests=AWL,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO sosnoski.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 May 2010 10:58:27 +0000 Received: from [83.161.120.155] (ip-409-564-7709.static-xdsl.xnet.co.nz [83.161.120.155]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id o43Aw0no009753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 06:58:05 -0400 Message-ID: <ydavis@example.org> Date: Mon, 03 May 2010 22:57:54 +1200 From: Dennis Sosnoski <ydavis@example.org> User-Agent: Thunderbird 83.161.120.155 (X11/20090822) MIME-Version: 1.0 To: ydavis@example.org CC: ydavis@example.org, ydavis@example.org Subject: Re: Performance Comparison References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andreas Veithen wrote: > On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <ydavis@example.org> wrote: > > ... >> >> So rather than an incremental build-on-demand model, I think an approach >> which just flipped DOM on or off at the message level would work just as >> well for web services. On the inbound side, if a SOAP Header is present >> you'd just always build a DOM representation of the Header part so it can be >> passed to handlers in an easily-manipulated form. If any of the handlers >> request the content of the SOAP Body you'd then build that as a DOM and pass >> it in. Outbound side is pretty much the same, with the data only requested >> from the data binding if needed to build the DOM and otherwise streamed >> directly to the output. Using this approach there's no need to build the DOM >> incrementally, other than at this very granular Header/Body level, so all >> that's required is a simple and high-performance DOM (or DOM subset) with >> just enough built-in smarts to recognize the Body expansion part, along with >> a StAX reader which takes a DOM as input. >> > > Sounds pretty much like CXF... > From what I've seen CXF always builds the DOM representation of the entire message and passes it to WSS4J anytime WS-Security is configured, just as Axis2 does (though Dan did add a check to disable response message WS-Security handling if only UsernameToken is used). The approach I'm suggesting would only build a DOM representation of the Body if the security handling actually signed or encrypted the Body (or any part of it). - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Tue May 04 01:19:31 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 62523 invoked from network); 4 May 2010 01:19:30 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 4 May 2010 01:19:30 -0000 Received: (qmail 59823 invoked by uid 500); 4 May 2010 01:19:30 -0000 Delivered-To: ydavis@example.org Received: (qmail 59706 invoked by uid 500); 4 May 2010 01:19:29 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 59698 invoked by uid 99); 4 May 2010 01:19:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 01:19:29 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO server.dankulp.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 01:19:22 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 7F83B2079F6D; Mon, 3 May 2010 21:19:00 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.1-gr2 (2007-05-02) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter.CM8G9F4gVZ Received: from dilbert.localnet (c-24-91-141-225.hsd1.ma.comcast.net [83.161.120.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id 091D72079490; Mon, 3 May 2010 21:18:58 -0400 (EDT) From: Daniel Kulp <ydavis@example.org> To: ydavis@example.org Subject: Re: Performance Comparison Date: Mon, 3 May 2010 21:19:05 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.33-gentoo; KDE/4.4.2; x86_64; ; ) Cc: Dennis Sosnoski <ydavis@example.org>, ydavis@example.org, ydavis@example.org References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <ydavis@example.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-3.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.1-gr2 On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote: > Andreas Veithen wrote: > > On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <ydavis@example.org> wrote: > >> So rather than an incremental build-on-demand model, I think an approach > >> which just flipped DOM on or off at the message level would work just as > >> well for web services. On the inbound side, if a SOAP Header is present > >> you'd just always build a DOM representation of the Header part so it > >> can be passed to handlers in an easily-manipulated form. If any of the > >> handlers request the content of the SOAP Body you'd then build that as > >> a DOM and pass it in. Outbound side is pretty much the same, with the > >> data only requested from the data binding if needed to build the DOM > >> and otherwise streamed directly to the output. Using this approach > >> there's no need to build the DOM incrementally, other than at this very > >> granular Header/Body level, so all that's required is a simple and > >> high-performance DOM (or DOM subset) with just enough built-in smarts > >> to recognize the Body expansion part, along with a StAX reader which > >> takes a DOM as input. > > > > Sounds pretty much like CXF... :-) Got a good chuckle out of that. :-) > From what I've seen CXF always builds the DOM representation of the > entire message and passes it to WSS4J anytime WS-Security is configured, > just as Axis2 does (though Dan did add a check to disable response > message WS-Security handling if only UsernameToken is used). The > approach I'm suggesting would only build a DOM representation of the > Body if the security handling actually signed or encrypted the Body (or > any part of it). I've thought of trying something similar to this by utilizing some sort of callback mechanism from WSS4J for finding the appropriate Element for a particular wsu:Id. The problem is that you cannot really 100% reliably figure out if we need the body or not from the policy, especially on server side where there could be different policies depending on the operation which we wouldn't know until a bit later. Thus, I'd like to be able to add something to WSS4J that it could use to find elements when there is a ref rather than always using an xpath search. There could be something more optimized put in place (like a simple String -> Element map for those elements already parsed) that could avoid the xpaths and such. However, it could also allow some delayed loading of the Body. Anyway, it's some stuff I've been noodling on a bit for a while. Not sure if I'll ever have time to actually do it. :-( Dan > > - Dennis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ydavis@example.org > For additional commands, e-mail: ydavis@example.org -- Daniel Kulp ydavis@example.org http://dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Tue May 04 01:31:29 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 63725 invoked from network); 4 May 2010 01:31:28 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 4 May 2010 01:31:28 -0000 Received: (qmail 72510 invoked by uid 500); 4 May 2010 01:31:28 -0000 Delivered-To: ydavis@example.org Received: (qmail 72428 invoked by uid 500); 4 May 2010 01:31:28 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 72420 invoked by uid 99); 4 May 2010 01:31:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 01:31:28 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=10.0 tests=AWL,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO server.dankulp.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 01:31:21 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 5ACF32079F60; Mon, 3 May 2010 21:31:01 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.1-gr2 (2007-05-02) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter.jaRrdrZXec Received: from dilbert.localnet (c-24-91-141-225.hsd1.ma.comcast.net [83.161.120.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id ED5F12079490; Mon, 3 May 2010 21:30:58 -0400 (EDT) From: Daniel Kulp <ydavis@example.org> To: ydavis@example.org Subject: Re: Performance Comparison Date: Mon, 3 May 2010 21:31:06 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.33-gentoo; KDE/4.4.2; x86_64; ; ) Cc: Dennis Sosnoski <ydavis@example.org>, Andreas Veithen <ydavis@example.org>, ydavis@example.org, Amila Suriarachchi <ydavis@example.org>, ydavis@example.org References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <ydavis@example.org> X-Old-Spam-Status: No, score=-3.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.1-gr2 On Monday 03 May 2010 3:20:36 am Dennis Sosnoski wrote: > Whoops, meant to have this in my first response... > > Andreas Veithen wrote: > > Each of the two approaches (porting WSS4J to Axiom / building a new > > optimized Axiom+DOM implementation) have their pros and cons and I > > think there is enough room for the two. They could even be > > complementary provided that the new Axiom+DOM implementation has a > > lower memory footprint and better performance. > > I can't really see much of a pro in porting WSS4J to Axiom. This would > mean either forking the code, with the associated maintenance issues, or > deliberately choosing to lower WSS4J's performance with other > applications just so that Axis2 improves (and creating an Axiom > dependency for everyone else using WSS4J). Just to extend this a bit further (or make it more generic), change this to: I can't really see much of a pro in porting <insert favorite XML processing library here> to Axiom. This would mean either forking the code, with the associated maintenance issues, or deliberately choosing to lower <insert favorite XML processing library here>'s performance with other applications just so that Axis2 improves (and creating an Axiom dependency for everyone else using <insert favorite XML processing library here>). Seriously, I really don't think the problem is limited to WSS4J. It really would apply to any library that does some sort of DOM based XML processing. Things like XSLT engines, XPath things, etc... Should ALL of them be forked to have Axiom versions? I personally think that's nuts. Let the security folks do security things. Let the XSLT folks do XSLT things. Etc... Let the Axiom folks concentrate on Axiom things. Standard API's are good for a reason. I would be good if the standard API's can be made to be fast. That's my opinion. Dan > > Implementing a DOM interface usable by WSS4J on top of a modified Axiom > seems like a better choice, so that Axis2 can avoid unnecessary > conversions and boost its performance without hurting other users of > WSS4J. Or instead using a simpler version of build-on-demand than that > implemented by Axiom, as discussed in the earlier reply. > > - Dennis -- Daniel Kulp ydavis@example.org http://dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Tue May 04 02:05:54 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 68145 invoked from network); 4 May 2010 02:05:53 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 4 May 2010 02:05:53 -0000 Received: (qmail 99403 invoked by uid 500); 4 May 2010 02:05:53 -0000 Delivered-To: ydavis@example.org Received: (qmail 99318 invoked by uid 500); 4 May 2010 02:05:53 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 99292 invoked by uid 99); 4 May 2010 02:05:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 02:05:53 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO sosnoski.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 02:05:44 +0000 Received: from [83.161.120.155] (ip-409-564-7709.static-xdsl.xnet.co.nz [83.161.120.155]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id o4425Hno014654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 22:05:21 -0400 Message-ID: <ydavis@example.org> Date: Tue, 04 May 2010 14:05:16 +1200 From: Dennis Sosnoski <ydavis@example.org> User-Agent: Thunderbird 83.161.120.155 (X11/20090822) MIME-Version: 1.0 To: Daniel Kulp <ydavis@example.org> CC: ydavis@example.org, ydavis@example.org, ydavis@example.org Subject: Re: Performance Comparison References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Daniel Kulp wrote: > On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote: > > ... > >> From what I've seen CXF always builds the DOM representation of the >> entire message and passes it to WSS4J anytime WS-Security is configured, >> just as Axis2 does (though Dan did add a check to disable response >> message WS-Security handling if only UsernameToken is used). The >> approach I'm suggesting would only build a DOM representation of the >> Body if the security handling actually signed or encrypted the Body (or >> any part of it). >> > > I've thought of trying something similar to this by utilizing some sort of > callback mechanism from WSS4J for finding the appropriate Element for a > particular wsu:Id. > > The problem is that you cannot really 100% reliably figure out if we need the > body or not from the policy, especially on server side where there could be > different policies depending on the operation which we wouldn't know until a > bit later. > > Thus, I'd like to be able to add something to WSS4J that it could use to find > elements when there is a ref rather than always using an xpath search. There > could be something more optimized put in place (like a simple String -> > Element map for those elements already parsed) that could avoid the xpaths and > such. However, it could also allow some delayed loading of the Body. > The nice thing about using a slightly-hacked and simplified DOM is that everything would be automatic - as it is with Axiom now, but with considerably less memory and processor overhead (because this approach would *only* defer building the DOM representation of the Body content, and would build the entire Body content as a DOM whenever anything within the Body was accessed - a lot of the memory and processor overhead of Axiom relates to the incremental one-element-at-a-time build process). And because it'd still implement the DOM interface (or at least a subset suitable for use by WSS4J) applications using WSS4J could choose to use this or continue to use any other DOM they want. - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Tue May 04 08:08:41 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 38434 invoked from network); 4 May 2010 08:08:40 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 4 May 2010 08:08:40 -0000 Received: (qmail 99630 invoked by uid 500); 4 May 2010 08:08:40 -0000 Delivered-To: ydavis@example.org Received: (qmail 98980 invoked by uid 500); 4 May 2010 08:08:35 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 98196 invoked by uid 99); 4 May 2010 08:08:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 08:08:33 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO fg-out-1718.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 08:08:26 +0000 Received: by fg-out-1718.google.com with SMTP id e12so1187559fga.16 for <multiple recipients>; Tue, 04 May 2010 01:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=cRItHdAiUvjmsxHqkwCd+bjz5rdbu7KCp7Apbnd7WuI=; b=b/IyS5lR4uuiuLLA+QCyfly99Bkc+1BHBhA07Iv3/P/bEsC91533cBqpBakJPuo+lv cbPgZVrJ4JvbNPNhdiTxtvkwhHMxb+G8WdjnGGm3mTOWwThm2GpvgBKYw4huWzkZg0M/ eLYc+WUZu1pVHpbFcyfTWVC9spQ31boMP475g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=qyURaSU2ggHkwSOyp8lGjpMMLjaKmEXI2HP8sVUxikwc5By7OfKVK4mkBCghzIjx0y Aac3t+5dyvvH/xKJYJUnQYAcft/IO0ZpKFiYCoK2hfIeC7fWQsX17Apg5qEe3XgAVy79 UeGa4VFoVyf5fTkHtMxyiRnwWtR+miQa+lEZE= Received: by 83.161.120.155 with SMTP id d4mr367367hbg.166.1272960486132; Tue, 04 May 2010 01:08:06 -0700 (PDT) MIME-Version: 1.0 Received: by 83.161.120.155 with HTTP; Tue, 4 May 2010 01:07:46 -0700 (PDT) In-Reply-To: <ydavis@example.org> References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> From: Andreas Veithen <ydavis@example.org> Date: Tue, 4 May 2010 10:07:46 +0200 Message-ID: <ydavis@example.org> Subject: Re: Performance Comparison To: Dennis Sosnoski <ydavis@example.org> Cc: Daniel Kulp <ydavis@example.org>, ydavis@example.org, ydavis@example.org, ydavis@example.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <ydavis@example.org> wrote: > Daniel Kulp wrote: >> >> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote: >> =A0... >> >>> >>> =A0From what I've seen CXF always builds the DOM representation of the >>> entire message and passes it to WSS4J anytime WS-Security is configured= , >>> just as Axis2 does (though Dan did add a check to disable response >>> message WS-Security handling if only UsernameToken is used). The >>> approach I'm suggesting would only build a DOM representation of the >>> Body if the security handling actually signed or encrypted the Body (or >>> any part of it). >>> >> >> I've thought of trying something similar to this by utilizing some sort = of >> callback mechanism from WSS4J for finding the appropriate Element for a >> particular wsu:Id. >> The problem is that you cannot really 100% reliably figure out if we nee= d >> the body or not from the policy, especially on server side where there c= ould >> be different policies depending on the operation which we wouldn't know >> until a bit later. >> Thus, I'd like to be able to add something to WSS4J that it could use to >> find elements when there is a ref rather than always using an xpath sear= ch. >> =A0 There could be something more optimized put in place (like a simple = String >> -> Element map for those elements already parsed) that could avoid the >> xpaths and such. =A0 However, it could also allow some delayed loading o= f the >> Body. >> > > The nice thing about using a slightly-hacked and simplified DOM is that > everything would be automatic - as it is with Axiom now, but with > considerably less memory and processor overhead (because this approach wo= uld > *only* defer building the DOM representation of the Body content, and wou= ld > build the entire Body content as a DOM whenever anything within the Body = was > accessed - a lot of the memory and processor overhead of Axiom relates to > the incremental one-element-at-a-time build process). And because it'd st= ill > implement the DOM interface (or at least a subset suitable for use by WSS= 4J) > applications using WSS4J could choose to use this or continue to use any > other DOM they want. Your statement assumes that the memory/processor overhead in Axiom is caused by the deferred parsing/building support. I don't think that is true. I think the reason is simply the way (the default implementations of) Axiom stores the information. For example, storing the attributes and namespace declarations of an element in hash maps is probably suboptimal. In SOAP messages, the average number of attributes (resp. namespace declarations) on elements having at least one attribute (resp. namespace declaration) is probably less then 2. Therefore the overhead of creating and maintaining a hash map is probably not justified by any gain in access performance. > =A0- Dennis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ydavis@example.org > For additional commands, e-mail: ydavis@example.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Tue May 04 09:22:39 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 52532 invoked from network); 4 May 2010 09:22:39 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 4 May 2010 09:22:39 -0000 Received: (qmail 81007 invoked by uid 500); 4 May 2010 09:22:39 -0000 Delivered-To: ydavis@example.org Received: (qmail 80568 invoked by uid 500); 4 May 2010 09:22:37 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 80552 invoked by uid 99); 4 May 2010 09:22:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 09:22:36 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ydavis@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO sosnoski.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 09:22:28 +0000 Received: from [83.161.120.155] (ip-409-564-7709.static-xdsl.xnet.co.nz [83.161.120.155]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id o449LKno017147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 May 2010 05:21:23 -0400 Message-ID: <ydavis@example.org> Date: Tue, 04 May 2010 21:21:08 +1200 From: Dennis Sosnoski <ydavis@example.org> User-Agent: Thunderbird 83.161.120.155 (X11/20090822) MIME-Version: 1.0 To: Andreas Veithen <ydavis@example.org> CC: Daniel Kulp <ydavis@example.org>, ydavis@example.org, ydavis@example.org, ydavis@example.org Subject: Re: Performance Comparison References: <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> <ydavis@example.org> In-Reply-To: <ydavis@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Andreas Veithen wrote: > On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <ydavis@example.org> wrote: > >> ... >>> >> The nice thing about using a slightly-hacked and simplified DOM is that >> everything would be automatic - as it is with Axiom now, but with >> considerably less memory and processor overhead (because this approach would >> *only* defer building the DOM representation of the Body content, and would >> build the entire Body content as a DOM whenever anything within the Body was >> accessed - a lot of the memory and processor overhead of Axiom relates to >> the incremental one-element-at-a-time build process). And because it'd still >> implement the DOM interface (or at least a subset suitable for use by WSS4J) >> applications using WSS4J could choose to use this or continue to use any >> other DOM they want. >> > > Your statement assumes that the memory/processor overhead in Axiom is > caused by the deferred parsing/building support. I don't think that is > true. I think the reason is simply the way (the default > implementations of) Axiom stores the information. For example, storing > the attributes and namespace declarations of an element in hash maps > is probably suboptimal. In SOAP messages, the average number of > attributes (resp. namespace declarations) on elements having at least > one attribute (resp. namespace declaration) is probably less then 2. > Therefore the overhead of creating and maintaining a hash map is > probably not justified by any gain in access performance. > Yes, I can see that it'd be possible to implement a deferred parsing/building approach at the element level without much added memory or processing overhead, if done correctly. There can really only be one parser in use, for instance, so that can be stored at the document level, and even the element currently being expanded could be stored at that level (rather than using a flag on the element). But is the flexibility gain from doing things this way worth the added complexity, as opposed to my suggestion of a tweaked DOM with a special kind of expandable Element used only for the Body (well, actually two kinds of expandable Elements, the second to handle MTOM attachments)? I don't know. - Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: ydavis@example.org For additional commands, e-mail: ydavis@example.org From ydavis@example.org Tue May 04 10:51:08 2010 Return-Path: <ydavis@example.org> Delivered-To: ydavis@example.org Received: (qmail 69153 invoked from network); 4 May 2010 10:51:06 -0000 Received: from unknown (HELO mail.apache.org) (83.161.120.155) by 83.161.120.155 with SMTP; 4 May 2010 10:51:06 -0000 Received: (qmail 55540 invoked by uid 500); 4 May 2010 10:51:05 -0000 Delivered-To: ydavis@example.org Received: (qmail 54633 invoked by uid 500); 4 May 2010 10:51:01 -0000 Mailing-List: contact ydavis@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:ydavis@example.org> List-Unsubscribe: <mailto:ydavis@example.org> List-Post: <mailto:ydavis@example.org> List-Id: <wss4j-dev.ws.apache.org> Delivered-To: mailing list ydavis@example.org Received: (qmail 54607 invoked by uid 99); 4 May 2010 10:50:59 -0000 Received: from nike.apache.org (HELO
{'source': 'Apache Software Foundation Public Mail Archives'}