Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-469

Make SMTP message queuing configurable (as an Handler)

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.3.0
    • Fix Version/s: 2.3.0
    • Component/s: SMTPServer
    • Labels:
      None

      Description

      The current message receiving code could be moved to an Handler to improve configurability.
      This need a configuration change in the default smtphandlerchain. I added a blocking configuration error message if there is no messagehandler configured.

      To do that we need to improve the lifecycle of the handlers: configurable and serviceable handlers must be supported.

      We could even move the chain configuration to an avalon component level (removing avalon/lifecycle specific code from the handler).

        Activity

        Hide
        bago Stefano Bagnara added a comment -

        Created the command, updated the default configuration. Upgraded the tests.
        The handler/chain lifecycle is still managed hardcoded and has not been promoted to toplevel avalon component.

        Show
        bago Stefano Bagnara added a comment - Created the command, updated the default configuration. Upgraded the tests. The handler/chain lifecycle is still managed hardcoded and has not been promoted to toplevel avalon component.
        Hide
        noel Noel J. Bergman added a comment -

        Excellent, thanks. If you go back and look at last year's discussions regarding pluggable handlers, you'll find the following in the e-mail archives:

        "The proposal I put forth wasn't just fast-fail, but pluggable in-protocol handler packages. In fact, as I envision it, the "base" package would include the default onMessage handler that knows how to post a message into the spool. That makes even that mechanism pluggable."

        So this is a good change.

        As for Avalon interfaces, I'd expect to move away from all such things when we "POJO-ify" JAMES.

        Show
        noel Noel J. Bergman added a comment - Excellent, thanks. If you go back and look at last year's discussions regarding pluggable handlers, you'll find the following in the e-mail archives: "The proposal I put forth wasn't just fast-fail, but pluggable in-protocol handler packages. In fact, as I envision it, the "base" package would include the default onMessage handler that knows how to post a message into the spool. That makes even that mechanism pluggable." So this is a good change. As for Avalon interfaces, I'd expect to move away from all such things when we "POJO-ify" JAMES.
        Hide
        danny@apache.org Danny Angus added a comment -

        Closing issue fixed in released version.

        Show
        danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

          People

          • Assignee:
            bago Stefano Bagnara
            Reporter:
            bago Stefano Bagnara
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development