Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > You are talking about injecting messages into JAMES.
> yep
> easy ways to inject messages is a frequent request from users and
> those extending JAMES
Yes, but 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?
> > One way: provide a simple wrapper around JavaMail. Sure, we can use
> > JMS and provide a Queue. Do you suggest that client coding for JMS
> > would be easier,
> maybe not so much easier as more familiar to the mainstream JEE crowd
JavaMail/Mail wrapper:
- desired for the purpose
- correct impedence match with JAMES
- client outline:
- sendMail(Sender, Recipients, Message[, Gateway])
- status is returned
JMS:
- significantly increased footprint for JAMES
- no standard for the payload
- 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
- create reply queue
- create consumer
- send message
- receive reply for status
Yes, we could write a wrapper, but that seems to beg the question.
> > and what happens when a message arrives on the queue? I don't mean
> > the JMS coding on our side -- that's trivial --
> the connection in JAMES is reasonable straightforward since ActiveMQ
> supplies the embedded JMS server (which is the hard bit).
No, again, I mean what do we do with it? 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.
> take a look at the experimental code. it's just an outline really. but
> if anyone's interested in developing it, it should just be a case of
> starting to extend the main classes...
> MailMessageListener is responsible for extracting the mail content
> from the message.
> MailBuilder is the strategy for converting message content -> Mail.
I'll search through the multi-part commit when I have time, unless you'd
like to outline things here. :-)
> FetchMail has a comprehensive implementation capable of dealing with
> wild emails which could be ported.) the mail->recipient mapping would
> be done here.
I consider this to be a really bad idea, as noted above. 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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
