ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dittmann, Werner (NSN - DE/Munich)" <>
Subject RE: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on the processing side if possible
Date Thu, 02 Dec 2010 16:20:15 GMT
Hi all,

just a thought here: why is this necessary or should be done? Enhance performance? Reduce
memory footprint?

Well, if I recall correctly then most of the processing time of WSS4J is spent in the 
crypto methods (public key processing in particular), signature processing and alike. IMHO

tuning the DOM processing does not really enhance the performance and these changes may
require quite some effort to do it.


Best regards,

-----Original Message-----
From: ext Colm O hEigeartaigh (JIRA) [] 
Sent: Thursday, December 02, 2010 3:34 PM
Subject: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on the processing
side if possible

Avoid converting the SOAP Body to DOM on the processing side if possible

                 Key: WSS-257
             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