On 9/22/06, Martin Landua <[EMAIL PROTECTED]> wrote:
Sure. The problem is though that we're talking about attachments, so there
maybe more than one in a message. And they might require different
encodings. Probably, this is hard to configure on the soap endpoint. Also,
the encoding might change from message to message.
So, from what I understand, the encoding is still a property of the
attachment itself (like it would be in an e-mail).
The encoding is a property of the serialized attachment, but once
it is deserialized (from base64 to binary stream for example), which
should happen on the BC side, the attachment is just a binary data,
right ? Also, you may want to be able to change the encoding
when going throught another BC ..
Therefore, an option might be to support some syntax like this:
<property
name="contentType"
value="application/octetstream; Content-Transfer-Encoding=base64"
/>
That's what would have to be implemented in SoapWriter, wouldn't it?
Or, another option, the problem lies in the class StreamDataSource? The
mail.jar package (during its guess of the encoding type) retrieves an
InputStream from the DataSource and since the class returns the
FileInputStream itself instead of a copy of it, a subsequent close() closes
the file. Would StreamDataSource return a "copy" of the stream, mail.jar
would guess the encoding, and once it wants to encode the file contents, it
would retrieve a second version of the stream, which is still readable from
the beginning. Sure, creating copies of input streams is pretty difficult.
InputStream may be good to avoid keeping the whole data in memory.
For example if you want to send a big binary file, using a stream
would be much more efficient than loading the whole file in memory.
Is this issue specific to sun mail.jar ? Have you tried with geronimo jar ?
Also, how does sun mail.jar guess the encoding ? I thought the encoding
was not tied to the content of the stream itself ...
I'm just thinking...
Regards
Martin
gnodet wrote:
>
> I think this content type encoding should be set somewhere on the
> soap endpoint, and maybe defaults to base64.
> As it is not related to the content itself, but its serialization, so
> there's
> no need to put it on the BinaryFileMarshaler (btw, there's no location
> to store such properties afaik...).
>
> Could you please raise a JIRA and provide a patch if you have one ?
>
> On 9/22/06, Martin Landua <[EMAIL PROTECTED]> wrote:
>>
>> 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.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
--
View this message in context:
http://www.nabble.com/Binary-SOAP-content-in-JMS-tf2310947.html#a6453193
Sent from the ServiceMix - User mailing list archive at Nabble.com.
--
Cheers,
Guillaume Nodet
