Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > what are the real-world use cases for using JMS as that method, and
> > how would it improve on JavaMail or a simple wrapper around it?
> by not having to run SMTP
Non-answer, unless the SMTP protocol is the problem, e.g., if you have a use
case where one might have JMS in an environment, and cannot (e.g., firewall)
use SMTP. The SMTP protocol need not be exposed to the client code, and it
is simpler to configure the client side of an SMTP transport than for JMS.
> JEE developers are familiar with JMS and unfamilar with mail.
I don't agree, plus you are talking about JEE developers who want to inject
a MAIL message into a MAIL server.
> SMTP has a well deserved reputation for being hard to administer.
That requires explanation. If you mean programs like sendmail, qmail,
postfix, et al, fine. But we're talking about client code, not server code.
> > JavaMail/Mail wrapper:
> which is fine if you want to run IMAP or SMTP
JAMES is a mail server, so unless/until we provide a different set of
matchers, mailets and other changes in the API, you're dealing with mail
(and/or news, which could be useful if we ever get around to addressing the
internal integration of NNTP with the mail pipeline).
> JMS:
> > - significantly increased footprint for JAMES
> only when it's assembled
That's like saying that gas is expensive only when I drive. :-)
> > - significantly more complex client:
> > - configure JNDI/JMS infrastructure as required
> > - create message
> > - create/lookup connection factory
> > - create connection
> > - create session
> > - create/lookup destination
> > - create producer
> this is all basic JMS which most JEE developers understand very well
Considering that my day job is teaching JEE and related, color me vastly
amused that you have this belief.
> FWIW these days, it would be most likely hidden inside a bus
Limitedly, and mostly in terms of MDB (either EJB or POJO type).
> > - create reply queue
> > - create consumer
> > - send message
> > - receive reply for status
> this is over-engineering for typical fire-and-forget use cases we're
> talking about
I don't agree. And if we support JMS on the server side, we should code to
support a reply-to destination.
> > The JAMES pipeline is based on SMTP routing information, which comes
> > from the envelope. And, no, JavaMail's MimeMessage is not sufficient,
> > unless you want to implement the assumptions forced upon FetchMail.
> > You want an explicit envelope for the message, which we would have to
> > invent and support.
> yes, just like FetchMail. JAMES is already more than a SMTP server.
> it's not unreasonable for users to ask (as they do) why if JAMES
> supports FetchMail, they can't inject mail into the spool.
Again, really bad idea. Fetchmail has to recreate the SMTP envelope from
what it finds in the message, and is not able to be accurate all the time.
If you want to do something with JMS, let's do it right.
> unless a mail is received via SMTP the envelope has to be derived from
> the headers in any case. JAMES already support this. the question you
> need to be asking yourself is if this new function is wrong then what
> needs to be fixed in the rest of JAMES?
It is not a matter of fixing Fetchmail. Fetchmail does the best it can to
deal with an information mismatch. There is no reason to provide a new,
ad-hoc, JMS injection point with a designed-in and unnecessary mismatch. As
I said:
> > If anything, I'd package it as a builder for use on the client side,
> > not the server side. The server side should expect a payload
> > containing a proper envelope and message.
So we provide a factory for creating a JMS message from any of several
origins, e.g., plain text + envelope, MimeMessage + envelope, MimeMessage
with derived envelope.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
