On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <[email protected]> wrote: > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen > <[email protected]> wrote: >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <[email protected]> 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 issues >>> 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 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/ > > Just for curiosity, have you done any performance comparison with your > implementation with any other implementation ?
Not yet. BTW, do you know of any existing (performance) test suite that tests WS-Security processing in isolation, i.e. without the need for a full SOAP stack (my project is ready for integration with WSS4J, but far from being ready to support Axis2)? > Sanka > > >> >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Sanka Samaranayake > > http://sankas.blogspot.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
