Timo,

Please create a JIRA issue with some code/wsdl whatever is needed to
recreate the problem.

thanks,
dims

On 5/19/06, Timo Ahokas <[EMAIL PROTECTED]> wrote:
Ok, I think I know what's happening...

----------[Example 1]------------
Client sends:
<OMElement>
  <OMElement>XML<OMELement>
  <OMElement>attachment 1</OMElement>
  <OMElement>attachment 2</OMElement>
  <OMElement>attachment 3</OMElement>
</OMElement>

Service receives:
<OMElement>
  <OMElement>XML<OMELement>
  <OMElement>attachment 1</OMElement>
</OMElement>

----------[Example 2]------------
Client sends:
<OMElement>
  <OMElement>XML<OMELement>
  <OMElement>
        <OMElement>attachment 1</OMElement>
        <OMElement>attachment 2</OMElement>
        <OMElement>attachment 3</OMElement>
  </OMElement>
</OMElement>

Service receives:
<OMElement>
  <OMElement>XML<OMELement>
  <OMElement>
        <OMElement>attachment 1</OMElement>
  </OMElement>
  <OMElement>attachment 2</OMElement>
</OMElement>

----------[Example 3]------------
Client sends:
<OMElement>
  <OMElement>XML<OMELement>
  <OMElement>
    <OMElement>
        <OMElement>attachment 1</OMElement>
        <OMElement>attachment 2</OMElement>
        <OMElement>attachment 3</OMElement>
    </OMElement>
  </OMElement>
</OMElement>

Service receives:
<OMElement>
  <OMElement>XML<OMELement>
  <OMElement>
    <OMElement>
        <OMElement>attachment 1</OMElement>
    </OMElement>
    <OMElement>attachment 2</OMElement>
  </OMElement>
  <OMElement>attachment 3</OMElement>
</OMElement>

So it seems that the code that is constructing the OMElement for the
service has a bug and it adding the attachments back incorrectly -
it seems to be adding any extra ones (2,3,...) to the parent
element, instead of the current one.

Anyone familiar with the code - where would this be handled?

Kind regards,
Timo

-----Original Message-----
From: Timo Ahokas [mailto:[EMAIL PROTECTED]
Sent: 19 May 2006 13:39
To: axis-user@ws.apache.org
Subject: RE: [Axis2] Vanishing MTOM attachments


Hi Thilina,

I tried what you suggested by doing this on the server side:

public OMElement service(OMElement element) {
  element.build();
  element.buildNext();
  element.detach();

  OMNode firstOMChild = element.getFirstOMChild();
  OMNode nextOMSibling = firstOMChild.getNextOMSibling();
  if(nextOMSibling != null) {
    OMNode nextOMSibling2 = nextOMSibling.getNextOMSibling();
    if(nextOMSibling2 != null) {
      OMNode nextOMSibling3 = nextOMSibling2.getNextOMSibling();
    }
  }
...

firstOMChild is the XML payload
nextOMSibling is the first binary attachment
nextOMSibling2 should be the second binary attachment (but is null)
nextOMSibling3 should be the third binary attachment (-||-)

I'm guessing that something is going wrong when the over-the-wire
data is being demarshalled and before the OMElement is even handed
down to my service (which would explain why I see the data
coming in into Axis, but not when it reaches my service). But I
could obviously misinterpret what the debugger is displaying.

>>And if the mime processing is deferred, why would the element contain
>>the first attachment (and not just the soap/xml part),
>
>Can't get your point clearly...

I think my point was that if all binary mime processing is deferred, then
why does one out of the three attachments come through fine? Unless
the first one is pre-loaded and any latter ones are deferred...

Has anyone successfully received multiple binary attachments with
Axis 1.0? :)

And Thilina - good luck with the exams... :)

Cheers
Timo

-----Original Message-----
From: Thilina Gunarathne [mailto:[EMAIL PROTECTED]
Sent: 19 May 2006 12:50
To: axis-user@ws.apache.org
Subject: Re: [Axis2] Vanishing MTOM attachments


Hi,
See my comments below


Thanks a lot for the response.

:) WC..



   public OMElement mediaTransformation(OMElement element) {
       try {
               element.build ();
               element.detach();
               Iterator serviceIterator = element.getChildElements();
               OMElement servicePayload = (OMElement)
serviceIterator.next();
               OMElement xmlDoc = (OMElement)
servicePayload.getChildElements().next();

               // Handle attachments, if there are any.
               DataHandler attachmentDH;

               while(serviceIterator.hasNext()) {
                       OMElement attachmentElement = (OMElement)
serviceIterator.next();
                       OMText attachment = (OMText)
attachmentElement.getFirstOMChild();
                       /* extract data and persist */
               }

               processXML(xmlDoc);

       } catch (Exception e) {
               e.printStackTrace();
       }

       return createResponseMessage();
   }

So when I get an element in, and inspect in the Eclipse debugger, I see the
XML content
and the first binary attachment, but none of the other attachments. When I
then let the
code run through, it extracts (and successfully saves to disc) the first
binary
attachment. But the iterator only contains one element, so none of the other
attachments

I doubt the problem is with getting the iterator.. IIRC there was a Jira
regarding this Iterator..
Try traversing the tree manually... Going through each and every Element
with getNextSibling, getChild..... Just to make sure where the problem is...

are processed. And I'm not currently returning the same content back anyway,
I'm
constructing a new response element from scratch.

I have tried with/without the element.build()/buildNext()/detach(), with no
changes
in behaviour. I wasn't able to find an omElement.buildAll() though?

Yeahh.. May be it's not there now. But I'm sure build() might be doing the
same thing.. I'm in touch with the code base a lot due to my oncoming exams
:)...




And if
the mime processing is deferred, why would the element contain the first
attachment
(and not just
the soap/xml part),


Can't get your point clearly...

~Thilina


as the on the wire message looks something like this:

POST /service HTTP/1.1
User-Agent: Axis/2.0
Host: 127.0.0.1
Transfer-Encoding: chunked
Content-Type: multipart/related;
boundary=MIMEBoundaryurn_uuid_1B620E94F835278E0E11480314414011;
type="application/xop+xml";
start="<0.urn:uuid:[EMAIL PROTECTED]>";
start-info="application/soap+xml"; charset=UTF-8

--MIMEBoundaryurn_uuid_1B620E94F835278E0E11480314414011
content-type: application/xop+xml; charset=UTF-8;
type="application/soap+xml";
content-transfer-encoding: binary
content-id: < 0.urn:uuid:[EMAIL PROTECTED]>

<!-- soap message with embedded XML content and include references to all
attachments -->

--MIMEBoundaryurn_uuid_1B620E94F835278E0E11480314414011
content-type: image/jpeg
content-transfer-encoding: binary
content-id: <1.urn:uuid:[EMAIL PROTECTED]>

<!-- binary content -->

--MIMEBoundaryurn_uuid_1B620E94F835278E0E11480314414011
content-type: image/jpeg
content-transfer-encoding: binary
content-id: < 2.urn:uuid:[EMAIL PROTECTED]>

<!-- binary content -->

--MIMEBoundaryurn_uuid_1B620E94F835278E0E11480314414011
content-type: image/jpeg
content-transfer-encoding: binary
content-id: <3.urn:uuid:[EMAIL PROTECTED]>

<!-- binary content -->

--MIMEBoundaryurn_uuid_1B620E94F835278E0E11480314414011--

To get this to run, I'm starting the client from a debugger and changing the
soapActionString ("\"\"") to an empty string (because othervise the parsing
fails on the server side).

Any ideas? Thanks - really appreciate your help... :)

Kind regards,
Timo

-----Original Message-----
From: Thilina Gunarathne [mailto:[EMAIL PROTECTED]
Sent: 19 May 2006 09:20
To: axis-user@ws.apache.org
Subject: Re: [Axis2] Vanishing MTOM attachments


You need to build the elements if you are going to echo them back to the
client.. IIRC you can call omElement.buildAll()  to overcome your problem...
Axis2 do deffered building of mime parts.. That means mime parts will be
read only if the user requests them...
In your case you are writing back the response while the attachments are
still in the stream which might be the cause for vanishing of other mime
parts...

~Thilina



On 5/18/06, Timo Ahokas <[EMAIL PROTECTED]> wrote:
Hi all,

We are using Axis2 1.0 (client & server) and sending XML and
binary MTOM attachments to the server. The XML document and the
first binary attachment are received without problems, but any
additional attachments never reach the server (are not available
from the OMElement when the server-side code starts executing).

I'm sending roughly the following from the client:

<OMElement>
<OMElement>
  <OMElement>
    XML document (constructed via StAXOMBuilder.getDocumentElement())
  </OMElement>
</OMElement>

<OMElement>
  <OMText>
    Binary attachment 1 (via factory.createOMText(datahandler, true))
  </OMText>
</OMElement>

<OMElement>
  <OMText>
    Binary attachment 2
  </OMText>
</OMElement>

<OMElement>
  <OMText>
    Binary attachment n
  </OMText>
</OMElement>
</OMElement>

This is sent out without problems from the client (as confirmed by
running through the Axis1 SoapMon proxy). The message on the wire
looks like fine, the first part of the multipart contains the
message (SOAP message with a XML payload and include references
for all the 1-n binary attachments) and each of the binary
attachments are included in separate parts of the message.

But when the message reaches the server, only the first binary
part seems to be in the OMElement that the server has constructed.
If I return that to the client, again looking at the wire
representation, only the first binary attachment is in place.

Also (possibly related to how the message is constructed), if I try
to set SOAP version to 1.2 on the client
(options.setSoapVersionURI(SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI)),
I get the following error on the server side:

2006-05-18 13:30:11,108 [ERROR][http-80-Processor24][ org.apache.catalina
.core.ContainerBase.[Catalina].[localhost].[/voxsurf].[AxisServlet]]:
Servlet.service() for servlet AxisServlet threw exception org.apache .
axiom.om.OMException: SOAPEnvelope must contain a body element which is
either first or second child element of the SOAPEnvelope.
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.getBody(SOAPEnvelopeImpl.ja
va:142)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.addChild
(SOAPEnvelopeImpl.j
ava:103)
at
org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.getHeader(SOAPEnvelopeImpl.
java:82)
at
org.apache.axis2.engine.AxisEngine.createFaultMessageContext
(AxisEngine.java
:183)
at
org.apache.axis2.transport.http.AxisServlet.handleFault(AxisServlet.java:168
)
at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:153)
at javax.servlet.http.HttpServlet.service ( HttpServlet.java:763)
...

But looking at the messages sent over the wire, only the soapenv
is different, and both messages start otherwise similarly:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";>
      <soapenv:Header/>
      <soapenv:Body>
        ... body content

Is there something fundamentally wrong in our approach for sending the
multiple binary attachments in the single message? Has someone been able to
do something similar using Axis2 1.0? Are there any debug flags etc
I could enable to see what happens when the message from the wire is
being processed?

Kind regards,
Timo Ahokas







--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
http://www.bloglines.com/blog/Thilina


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
http://www.bloglines.com/blog/Thilina


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to