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