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: [email protected]
For additional commands, e-mail: [email protected]
