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.
- Dennis
