On 6/12/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
This is a bit primative, albeit not dissimilar from MQSeries. We can improve upon it, e.g., by looking up queue managers -- implementation and all -- from JNDI as shown, but I am trying to not assume that every implementation will have JNDI or JMS or JDBC pervasive throughout the system.
I would think it would be good to learn the patterns used by JMS implementations, like MQSeries and emulate those (not that JMS is a particularly well designed spec, but..). To me this plan largely sounds like we are effectively a queuing server. Whether that's the goal or not, I just mean to point out that there are very robust implementations that do this, and we could learn from them as examples.
And, yes, the queue manager would continue to be responsible for calling the processor to handle each message. Each queue manager would be registered with the MailetContext, which would be provided to the processor in order to allow it to put messages set to a new processor (if we keep the currently Mailet API). We might provide a suitable error or exception on the Mail.setState call if we try to address a queue (processor) that does not exist.
If I had to do any one thing about the mailet API over, it would be Mail.setState. I think it's very counterintuitive and just doesn't make sense. What it is simulating... a) letting the mailet indicate that it has consumed the message. b) injecting this mailet into another spool We then do mailconfig.sendMail to simulate b) in another areas. It's just really messy... the constants make no sense and nevermind the terrible name "Ghost" to say a message is consumed. Anyway, so rather than checking on mail.setState, provide a way the message into another spool and fail there, deprecating mail.setState a.s.a.p. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
