On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <[email protected]> wrote: > 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.
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. > - 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]
