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 ? 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]
