Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-5162

SOAP - Externalize binary content in the payload as an attachment automatically

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Done
    • Major
    • jboss-fuse-6.3
    • jboss-fuse-6.2.1
    • SwitchYard
    • None
    • % %

    Description

      The decompose method of the class org.switchyard.component.soap.composer.SOAPMessageComposer does not make use of the _mtomEnabled && _xopExpand flags.
      This results to the behaviour that a client calling an switchyard endpoint with MTOM/xop gets a result with inlined base64 encoded attachments with is no symmetrical behaviour. I would expect that the decompose method converts the attachments back to MTOM.

      To clarify the case:

      • Switchyard offers a SOAP Webservice with mtom enabled.
      • The client sends a request with correct mtom/xop attachments.
        (To process the attachments in our switchyard project we now have to set xopExpand=true due to https://issues.jboss.org/browse/ENTESB-5161)
      • The client expects mtom/xop in the response, but receives attachments as base64 inline. (which, as a side effect, also means that the server has to include the base64 attachment for the calculation of the signature/encryption...)

      To be symmetrical the decompose method should have a counterpart to the call of 'bodyNode = SOAPUtil.expandXop((Element)bodyNode, attachments)' in the compose method:

      https://github.com/jboss-switchyard/components/blob/master/soap/src/main/java/org/switchyard/component/soap/composer/SOAPMessageComposer.java#L168-L168

      Attachments

        Issue Links

          Activity

            People

              toigaras@redhat.com tomohisa igarashi
              rhn-support-mputz Martin Weiler (Inactive)
              Stefan Veres Stefan Veres
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: