ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Commented: (WSS-257) Avoid converting the SOAP Body to DOM on the processing side if possible
Date Thu, 02 Dec 2010 15:43:10 GMT


Daniel Kulp commented on WSS-257:

I'm also kind of wondering if it should be:

Source  getElementForID(Object msgContext, String i)

instead with a possible initial restriction of only DOMSource is allowed.    At some point,
it MAY make some sense for the incoming side to allow some level of streaming.   Obviously,
a LOT of changes would be required to do that.   

Another question:  does it need a flag to say what the use case is for?  Signature or encryption?
   With encryption, we know the contents of the returned Source are irrelevant (will be replaced
with the decrypted content), but for signature, it's just walking/checking.  Thus, we could
potentially optimize things differently in the two cases.   Maybe I'm over thinking things.

The encryption case may require an additional method like:

void replaceElement(Element encrypted, Element decrypted)

When the encryption has the entire Element encrypted (and not just the content), then it needs
to be replaced.   In the REST case we talked about on CXF, the encrypted element may not have
a parent as it's not wired into a SOAP message.  Thus, we wouldn't really have a way to find
out if it was replaced or not unless we force the use of DocuementFragments or something.

> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>                 Key: WSS-257
>                 URL:
>             Project: WSS4J
>          Issue Type: Improvement
>    Affects Versions: 1.5.10
>            Reporter: Colm O hEigeartaigh
>            Assignee: Colm O hEigeartaigh
>             Fix For: 1.6
> On an inbound request, WSS4J currently iterates through each security token in the security
header and processes each one. However it also requires the entire SOAP request be converted
into a DOM structure, even though it might not be necessary to access the SOAP body as part
of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access
to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback
mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide
support for signed MTOM. WSS4J should supply a default implementation that more or less parallels
the current implementation. CXF/Rampart etc. could define their own callback implementations
for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
>    return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
>    return null;
> }
> }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message