Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: PC

      Description

      With the removal of the ByteArrayDataSource class, there is no easy method for
      attaching dynamically generated content to an email. The attach() methods in
      MultipartEmail and the EmailAttachment class want either a File, URL, or
      DataSource. We should add the ability to easily attach byte[] attachments so
      that users are not required to implement their own DataSource.

        Activity

        Hide
        Corey Scott added a comment -

        Created an attachment (id=13475)
        adds an attachment method that takes and byte[] as input

        Scott,

        This is just a quick kludge, is this the sort of thing you are talking about?
        Do you think you would be able to contrib a test case for this? I have to
        admit, I dont use this particular functionality and an experienced eye would be
        greatly helpful.

        -Corey

        Show
        Corey Scott added a comment - Created an attachment (id=13475) adds an attachment method that takes and byte[] as input Scott, This is just a quick kludge, is this the sort of thing you are talking about? Do you think you would be able to contrib a test case for this? I have to admit, I dont use this particular functionality and an experienced eye would be greatly helpful. -Corey
        Hide
        Scott added a comment -

        It doesn't look like creating a MimeBodyPart with an InputStream gives the
        expected result here...I think it expects the InputStream to contain MIME
        headers (which it attempts to parse). Looking things over, it certainly looks
        like a new DataSource is the best/fastest path to fixing this issue (much like
        the existing attach() methods use FileDataSource and URLDataSource in the
        javax.activation package).

        Show
        Scott added a comment - It doesn't look like creating a MimeBodyPart with an InputStream gives the expected result here...I think it expects the InputStream to contain MIME headers (which it attempts to parse). Looking things over, it certainly looks like a new DataSource is the best/fastest path to fixing this issue (much like the existing attach() methods use FileDataSource and URLDataSource in the javax.activation package).
        Hide
        Corey Scott added a comment -

        in that case, the resurecting the previous class (maybe even marking it a an
        util class, or similar) might be the best option.

        Show
        Corey Scott added a comment - in that case, the resurecting the previous class (maybe even marking it a an util class, or similar) might be the best option.
        Hide
        Corey Scott added a comment -

        Created an attachment (id=13524)
        Please refer to matching commetn

        It appears that we were a little too hasty to remove the deprecated
        ByteArrayDataSource class. In this patch, I propose that we resurrect it, and
        remove the deprecated marker.

        I have also provided a convenience method for the MultipartEmail class that
        allows an Byte[] as a input to the attach method. If this solves this issue I
        will contribute relevant unit tests to cover this method.

        (PS. I realise that you are not suppose to add patches when the component is
        under a promotion vote, but I couldnt wait any longer. These methods are NOT
        exactly requried, but I believe they should be included before RC1)

        Show
        Corey Scott added a comment - Created an attachment (id=13524) Please refer to matching commetn It appears that we were a little too hasty to remove the deprecated ByteArrayDataSource class. In this patch, I propose that we resurrect it, and remove the deprecated marker. I have also provided a convenience method for the MultipartEmail class that allows an Byte[] as a input to the attach method. If this solves this issue I will contribute relevant unit tests to cover this method. (PS. I realise that you are not suppose to add patches when the component is under a promotion vote, but I couldnt wait any longer. These methods are NOT exactly requried, but I believe they should be included before RC1)
        Hide
        Corey Scott added a comment -

        Created an attachment (id=13563)
        New patch against commons (not commons-sandbox), no other changes

        Show
        Corey Scott added a comment - Created an attachment (id=13563) New patch against commons (not commons-sandbox), no other changes
        Hide
        David Eric Pugh added a comment -

        I have applied back the ByteArrayDataSource.. However, I thought about the
        convenicenc method and on MultiPartEmail and decided against it. I realized
        that over time we may have multiple *DataSource, so we really should have the
        user convert the object (in this case byte[]) to the datasource, and just hand
        that in, otherwise we pollute the api with lots of conveniece methods.

        I can't seem to commit right now, but I will. If you can come up with a unit
        test, that would be cool too.

        Show
        David Eric Pugh added a comment - I have applied back the ByteArrayDataSource.. However, I thought about the convenicenc method and on MultiPartEmail and decided against it. I realized that over time we may have multiple *DataSource, so we really should have the user convert the object (in this case byte[]) to the datasource, and just hand that in, otherwise we pollute the api with lots of conveniece methods. I can't seem to commit right now, but I will. If you can come up with a unit test, that would be cool too.
        Hide
        David Eric Pugh added a comment -

        Restored the ByteArrayDataSource and committed.

        Show
        David Eric Pugh added a comment - Restored the ByteArrayDataSource and committed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Scott
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development