On Dec 1, 2007 6:57 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > 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?
by not having to run SMTP JEE developers are familiar with JMS and unfamilar with mail. JAMES offers a friendly, flexible java face and can do POP3. SMTP has a well deserved reputation for being hard to administer. > > > 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 which is fine if you want to run IMAP or SMTP > JMS: > - significantly increased footprint for JAMES only when it's assembled > - no standard for the payload text...? > - 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 FWIW these days, it would be most likely hidden inside a bus > - 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 > Yes, we could write a wrapper, but that seems to beg the question. why would we need to write a wrapper? JEE developers understand JMS very well. i have no doubts about their ability to create a text message and push it onto a queue. > > > 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. 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. > > 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. :-) code's clearer and quicker than words > > 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. 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? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
