So, from a user's perspective, all they have to do to enable SOAP is click a checkbox?

From a testing perspective, it's sounding like we'll be adding a de facto SOAP pre-processor, and that the policy-related code will not be changing?


On Thu, Apr 21, 2016 at 12:16 PM, Eric Wittmann <> wrote:
I'd like to reboot the discussion around SOAP support in apiman. Originally I was thinking we could implement it without parsing the full message.  I even have some code for doing this.

However, after thinking about it some more (and after some discussion about soapaction vs. resource path in a separate jira) I'm thinking we simply have an option that will parse the entire soap message upfront *as an option*.

I'd like any opinions anyone might have on this matter.  :)  The idea would be to handle the soap message in a java-standard fashion (jax-ws, javax.xml.soap, SAAJ, etc).  The resulting soap message would be available to policies as part of the policy context, and it could be processed however the policy wants.

When proxying to the back-end, the (possibly modified) soap message will be serialized to a string and written to the back-end API.


Question for @Keith primarily:  do you have any advice/code that efficiently parses a soap message?  And is there someone you've worked with that has a lot of SOAP experience who could perhaps chime in some expertise?


Len DiMaggio (
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886  USA
tel:  978.392.3179
cell: 781.472.9912