Could you explain what Problems you See here? Also the Queues would Be of the type MailQueue, so its not limited to jms. The configuration of the Services would Be Done by seperate config Files....
Bye Norman Am Sonntag, 9. Januar 2011 schrieb Eric Charles <eric.char...@u-mangate.com>: > Hi, > > I also like the idea to have remote/local delivery as core service > implemented via JMS queues. > The decision to deliver should remain in the mailet processor. > > The way the local/remote delivery queues will be consumed will be configured > via separate mechanisms (xml files). > > The question is also "how to configure the local/remote delivery queues > consuming": via another mailet chain, via camel-like routes, yet-another > ad-hoc config ? > Don't we simply move the problem from the current mailet processors to an > other component, with JMS queues between ? > > But yes, I like the idea. > Tks, > > Eric > > On 8/01/2011 19:10, Norman Maurer wrote: > > Well I thought more about doing the splitting in the Delivery > dispatcher.. something like: > > * retrieve mail from queue > * check if mail attribute "prepared" set > * attribute not found: > * do the splitting if needed > * set attribute "prepared" > * store back in queue > * attribute found: > * start delivering > > This would allow is todo the configure of the gateway etc only one > time and all at the same place. > > The other think we could do is configure in the "ToRemoteDelivery" and > store the config stuff as mail attributes, but this is not so > "clean".. > > I would prefer 1) > > WDYT ? > Norman > > > 2011/1/8 Stefano Bagnara<apa...@bago.org>: > > 2011/1/7 Norman Maurer<nor...@apache.org>: > > Hi there, > > I spend the last weeks to think about RemoteDelivery and how it is > implemented. I think putting the remote deliver code in a Mailet is > not a good idea. It does not give us much control about it and makes > it harder to customize or extend. I think it would make more sense to > make the delivery code a "core service" which should allow some kind > of pluggable policy out-of-the-box. The Mailet should just move the > mail to the right queue then which the mail will get pulled of from > the new "core service" and tried to get delivered. > > Beside of that I think we should add some kind of policy support which > allow to register policies/listener which customize the following > things: > > * Calculate the next delay > * Force an other ip address as source for the next delivery attemp > * Force an other ip address as destionation for the next delivery attemp > > After that is done I think it would be very easy to add JMX metrics to > the service as well... > > WDYT ? > > Do you think of simply using a ToRepository or something more specific? > The main issue with using a simple ToRepository is that currently > RemoteDelivery had some "logic" before writing to the outgoing spool. > In fact depending on the presence of a gateway conf or not it will > split the message for each recipient (or recipient group) depending on > the final domain. > > If we instead use a simple ToRepository then we'll have to do one more > processing in order to split the message in a following step. > > So, i think we should still have a ToRemoteDelivery mailet or something > similar. > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
