[
http://jira.jboss.com/jira/browse/JBWS-2026?page=all ]
Thomas Diesler updated JBWS-2026:
---------------------------------
Fix Version/s: jbossws-native-2.0.5
Assignee: Heiko Braun
Heiko, please have a look if this is a valid change
jax-ws and saaj attachments
---------------------------
Key: JBWS-2026
URL:
http://jira.jboss.com/jira/browse/JBWS-2026
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-2.0.3
Environment: jboss as 4.2.2 + jbossws 2.0.3
Reporter: Mirko Ravagnan
Assigned To: Heiko Braun
Fix For: jbossws-native-2.0.5
Attachments: CommonSOAPBinding.java
Dear jbossws developers.
I'm having an issue dealing with a webservice provided from a third party.
The problem I encountered is as follows:
1: the service returns as output some data in the response
and an optional attachment sent with saaj.
2: the attachment comes along and is stored
in a temporary directory by jboss.
3: jbossws fails to identify the attachment and does not bind it
to the response of the service.
4: jboss throws the unused attachment away.
I've tracked the issue on the class CommonSoapBinding
in class org.jboss.ws.core.
This issue is related to the inability of the mentioned class
to deal with attachment by id, but only by part name.
The fact is the service provider sends attachment
without sending the content id complete with the part name
let me explain:
The http headers sent with the response message do not contain
a header [Content-Id="MyAttachment=<blablabla...>"]
but [Content-Id="<blablabla...>"]
Hence, method "getAttachmentFromMessage" fails to find the attachment.
As a solution, I made some modification to that method in order
it to deal with the requirement to handle attachments by id.
I also modified the behaviour of the method not to throw an exception
when it does not find the attachment it expects to find, because otherwise
you might loose the chance to get fault text messages embedded in the service
response, as this exception breaks the process of rebuilding the java
representation of the soap message.
This is reflected also in method "unbindResponseMessage".
I'm attaching the modified java source
so that you can have evidence of the changes
(which have a comment "\\ m." on the right side of the line)
Many thanks for your time
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira