Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 1.1
    • Labels:
      None
    • Environment:

      Operating System: Windows XP
      Platform: Other

      Description

      This is not a bug, it is a Feature Request.

      It should be nice if the framework implements a way to create a MultiPartMessage
      from an InputStream or a String with all the content of a real message got from
      a POP3 or NNTP server.

      Currently it seems you have to create it manually adding headers and parts via
      methods. And I think in this way is not really useful.

      Thanks,

      Chemi.

        Activity

        Hide
        dion gillard added a comment -

        Sounds ok for post 1.0

        Show
        dion gillard added a comment - Sounds ok for post 1.0
        Hide
        dion gillard added a comment -

        Post 1.0 enhancements

        Show
        dion gillard added a comment - Post 1.0 enhancements
        Hide
        Ben Speakmon added a comment -

        One of the MimeMessage constructors in JavaMail (both 1.3 and 1.4) already does this, BTW.

        I'm not sure this is something that falls within commons-email's scope. The commons-email API, I think, is for the common cases where you just want to build and send an email without needing the power (or complexity) of JavaMail. If you're already pulling messages from an email server, I don't know why you wouldn't just use JavaMail for manipulating it – the power and complexity is just what you need for those kinds of jobs. And it doesn't seem worth the trouble to duplicate any of that code in commons-email when the existing code works just fine.

        If you can suggest a compelling use case for this, I can look further into it.

        Show
        Ben Speakmon added a comment - One of the MimeMessage constructors in JavaMail (both 1.3 and 1.4) already does this, BTW. I'm not sure this is something that falls within commons-email's scope. The commons-email API, I think, is for the common cases where you just want to build and send an email without needing the power (or complexity) of JavaMail. If you're already pulling messages from an email server, I don't know why you wouldn't just use JavaMail for manipulating it – the power and complexity is just what you need for those kinds of jobs. And it doesn't seem worth the trouble to duplicate any of that code in commons-email when the existing code works just fine. If you can suggest a compelling use case for this, I can look further into it.
        Hide
        Henri Yandell added a comment -

        (Setting fixVersion to 1.1 not to imply that it should be fixed in 1.1, but that a decision should be made on this issue as a part of 1.1)

        Show
        Henri Yandell added a comment - (Setting fixVersion to 1.1 not to imply that it should be fixed in 1.1, but that a decision should be made on this issue as a part of 1.1)
        Hide
        dion gillard added a comment -

        I'm with Ben on this one. I think javamail is the appropriate tool for this sort of activity and it falls outside of what we're trying to do (keep it as simple as it needs to be) with commons email.

        I'm happy to hear alternative views on it, though...

        Show
        dion gillard added a comment - I'm with Ben on this one. I think javamail is the appropriate tool for this sort of activity and it falls outside of what we're trying to do (keep it as simple as it needs to be) with commons email. I'm happy to hear alternative views on it, though...
        Hide
        Henri Yandell added a comment -

        I agree too - so resolving this and suggesting that if anyone thinks it has value that they should reopen the issue.

        Show
        Henri Yandell added a comment - I agree too - so resolving this and suggesting that if anyone thinks it has value that they should reopen the issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jose M. Ordax
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development