Uploaded image for project: 'Axis2-C'
  1. Axis2-C
  2. AXIS2C-1181

Unable to support MTOM for code generation with adb

    XMLWordPrintableJSON

Details

    • New Feature
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.4.0
    • None
    • code generation
    • None
    • CentOS 4.4

    Description

      Hello group,

      I have a service which receives an MTOM attachment, and the service sends back the same.
      I generated the service skeleton code with adb from the wsdl .
      The wsdl describes the data exchanged to be of type xmime:base64binary.
      I am able to receive the MTOM attachment at the client and save it to a file.
      In the business logic of the service, i wrote the code to create the datahandler from the file received.
      But i found that the code that is serializing the xop node is converting it to a string using axiom_node_to_string API.
      Because of which i am unable to see the attachment at the client end.

      For Instance:

      Sample server response to client as observed in tcpmon

      ---MIME boundary
      <soapenvelope>
      <soapbody>
      <BinaryData><xop node serialized as string></BinaryData>
      </soapbody>
      </soapenvelope>
      ----MIME boundary

      ----MIME boundary
      No attachment(empty)
      ----MIME boundary

      Serializer logic:

      It is enclosing the xop node in between the tags <BinaryData> and </BinaryData>.
      Its converting xop node to string using axiom_node_to_string(xop_node,env)l

      How to generate code with proper serializers to send MTOM from the service with adb???
      Kindly let me know if you need more details.

      Thanks in advance,
      Naveen Bhat

      Attachments

        Activity

          People

            Unassigned Unassigned
            navinbhat naveen bhat
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:

              Time Tracking

                Estimated:
                Original Estimate - 48h
                48h
                Remaining:
                Remaining Estimate - 48h
                48h
                Logged:
                Time Spent - Not Specified
                Not Specified