There isn't a stack trace, actually. It's just that the (soap-unmarshalled)
binary, which I receive from JMS is exactly 4KB too short.
I then replaced activation.jar and mail.jar (delivered from JBoss) by the
most recent versions from Sun (for which I have the source code) and there I
figured out that mail.jar tries to guess the content encoding from reading
the first 4KB (and, furthermore, in the Sun-version, it closes the stream
after guessing).
To solve this, I modified the method writeMultipartMessage in
org.apache.servicemix.soap.marshalers.SoapWriter and hard-coded the
content-type-encoding to base64. Then it works. But I guess that's not what
we want.
Regards
Martin
for (Iterator itr = message.getAttachments().entrySet().iterator();
itr.hasNext();) {
Map.Entry entry = (Map.Entry) itr.next();
String id = (String) entry.getKey();
DataHandler dh = (DataHandler) entry.getValue();
MimeBodyPart part = new MimeBodyPart();
part.setDataHandler(dh);
part.setContentID("<" + id + ">");
//////// I added this
part.setHeader("Content-Transfer-Encoding", "base64");
////////
parts.addBodyPart(part);
}
gnodet wrote:
>
> Do you have the full stack trace of the exception ?
> Also, where is the stream read and closed to determine
> content-type-encoding ?
>
> On 9/21/06, Martin Landua <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I'm trying to read a binary file from the disk using the file poller and
>> write its contents into a JMS queue. I figured out that the
>> BinaryFileMarshaller can be equipped with the content type, which I have
>> set
>> to "application/octetstream".
>> Now, the problem is that the conversion into a SOAP message fails. This
>> seems to be due to the fact that the xfire components try to determine
>> the
>> content-type-encoding by reading the first 4KB of the file.
>> Unfortunately,
>> xfire seems to close the stream (i.e. the file) afterwards and
>> consequently
>> the stream is still closed when xfire tries to create the Base64 encoded
>> SOAP message.
>>
>> Is there any way that I can specify the content-encoding-type within the
>> BinaryFileMarshaller in order to skip the abovementioned "autodetection"
>> of
>> the encoding? I tried "application/octetstream;
>> content-type-encoding=base64" but that did not work. Of would I have to
>> use
>> a different content type? Or can I tell xfire to use base64 encoding
>> without
>> testing the file?
>>
>> Please note that we use ServiceMix using the JBoss Installer in JBoss
>> 4.0.4-GA.
>>
>> Regards
>>
>> Martin
>>
>> <sm:activationSpec componentName="filePoller"
>> service="foo:filePoller"
>> destinationService="foo:jmsFileIn">
>> <sm:component>
>> <bean
>>
>> class="org.apache.servicemix.components.file.FilePoller">
>> <property name="file"
>> value="d:/tmp/wmreader" />
>> <property name="period"
>> value="5000" />
>> <property
>> name="marshaler">
>> <bean
>>
>> class="org.apache.servicemix.components.util.BinaryFileMarshaler">
>> <property
>> name="contentType"
>>
>> value="application/octetstream; Content-Transfer-Encoding=base64"
>> />
>> </bean>
>> </property>
>> </bean>
>> </sm:component>
>> </sm:activationSpec>
>>
>> <sm:activationSpec componentName="jmsFileIn">
>> <sm:component>
>> <jms:component>
>> <jms:endpoints>
>> <jms:endpoint
>> service="foo:jmsFileIn"
>>
>> endpoint="endpoint" role="provider" destinationStyle="queue"
>>
>> processorName="jca" jndiDestinationName="queue/C"
>>
>> jndiConnectionFactoryName="java:/JmsXA" soapVersion="1.2"
>>
>> soap="true" />
>> </jms:endpoints>
>> </jms:component>
>> </sm:component>
>> </sm:activationSpec>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Binary-SOAP-content-in-JMS-tf2310947.html#a6425095
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
--
View this message in context:
http://www.nabble.com/Binary-SOAP-content-in-JMS-tf2310947.html#a6443700
Sent from the ServiceMix - User mailing list archive at Nabble.com.
