[
https://issues.apache.org/jira/browse/EMAIL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Hubert updated EMAIL-209:
------------------------------
Description:
After upgrading from commons-email 1.5 to 1.6.0 an integration test of a custom
MessageHandler implementation taking care of attachments broke, as attachments
were no longer correctly processed.
I had a brief look at this custom implementation and noticed that
org.apache.commons.mail.util.MimeMessageParser#getAttachmentList
was used to retrieve the list of attachment data source and processed it twice
relying on the javax.activation.DataSource contract of #getInputStream():
"Note that a new InputStream object must be returned each time this method is
called, and the stream must be positioned at the beginning of the data."
which was working just fine with commons-email 1.5 being backed by
javax.mail.util.ByteArrayDataSource.
It looks like with EMAIL-207 a new implementation
org.apache.commons.mail.activation.InputStreamDataSource was introduced which
current implementation seems to violate this contract. Calling getInputStream
does not provide a fresh InputStream at the beginning of the data, but returns
the existing object in the state of the previous usage, resulting in incomplete
data processing.
was:
After upgrading from commons-email 1.5 to 1.6.0 an integration test of a custom
MessageHandler implementation taking care of attachment broke, as attachments
were no longer correctly processed.
I had a brief look at this custom implementation and noticed that
org.apache.commons.mail.util.MimeMessageParser#getAttachmentList
was used to retrieve the list of attachment data source and processed it twice
relying on the javax.activation.DataSource contract of #getInputStream():
"Note that a new InputStream object must be returned each time this method is
called, and the stream must be positioned at the beginning of the data."
which was working just fine with commons-email 1.5 being backed by
javax.mail.util.ByteArrayDataSource.
It looks like with EMAIL-207 a new implementation
org.apache.commons.mail.activation.InputStreamDataSource was introduced which
current implementation seems to violate this contract. Calling getInputStream
does not provide a fresh InputStream at the beginning of the data, but returns
the existing object in the state of the previous usage, resulting in incomplete
data processing.
> InputStreamDataSource#getInputStream() violates javax.activation.DataSource
> contract
> ------------------------------------------------------------------------------------
>
> Key: EMAIL-209
> URL: https://issues.apache.org/jira/browse/EMAIL-209
> Project: Commons Email
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Eric Hubert
> Priority: Major
>
> After upgrading from commons-email 1.5 to 1.6.0 an integration test of a
> custom MessageHandler implementation taking care of attachments broke, as
> attachments were no longer correctly processed.
> I had a brief look at this custom implementation and noticed that
> org.apache.commons.mail.util.MimeMessageParser#getAttachmentList
> was used to retrieve the list of attachment data source and processed it
> twice relying on the javax.activation.DataSource contract of
> #getInputStream():
> "Note that a new InputStream object must be returned each time this method is
> called, and the stream must be positioned at the beginning of the data."
> which was working just fine with commons-email 1.5 being backed by
> javax.mail.util.ByteArrayDataSource.
> It looks like with EMAIL-207 a new implementation
> org.apache.commons.mail.activation.InputStreamDataSource was introduced which
> current implementation seems to violate this contract. Calling getInputStream
> does not provide a fresh InputStream at the beginning of the data, but
> returns the existing object in the state of the previous usage, resulting in
> incomplete data processing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
