Hey Norman, 

Thanks again for your response. We are suppose to start accepting incoming 
email later this month. But are not due to be in production for a few more 
months. 

I'll take a look at your options and ideas and see what I can come up with. 

Thanks,
Mike


On Apr 7, 2010, at 9:54 PM, Norman Maurer wrote:

> Hi Mike,
> 
> chaining UsersRepositories is not supported out of the box. But it
> should be easy to implement it by yourself with a UserRepository
> implementation which acts as "proxy" and just "query" the
> implementions you want to use..
> 
> About the error processing, it depends..
> 
> First off, when do you expect to complete your app (when it goes to
> production) ? I think I would use james trunk in any case but your
> view might be a bit different. Current trunk uses camel for calling
> the actual Mailets so its a bit more flexible in terms of Exception
> handling etc.
> 
> A solution which should work with both james version is to set the
> "state" of the Mail object to an extra processor. In the processor
> your put the Mail in some kind of MailRepository (or something else
> which is developed by you). Then you write a RetryMailDelivery Service
> which will fire of the Mails (which was stored before) again.
> 
> If you want some more details on how things could work out, just ask..
> 
> Bye,
> Norman
> 
> 2010/4/7 Mike Dougherty <[email protected]>:
>> Hey Norman,
>> 
>> Thanks for your response. Yeah, I think a UsersRepository would be a good 
>> way to go. Can I chain repositories? For example, first check the 
>> VirtualUsersRepository then check MyCustomUsersRepository, if both fail to 
>> find user, bounce message?
>> 
>> My application is just using the MimeMessage for its processing. I've built 
>> a quick and dirty Mailet, which seems to be getting the job done. However, 
>> one thing I have yet to figure out is how to handle error conditions. Most 
>> notable, if the Mailet cannot access my apps web service, I would like to 
>> queue the message for later processing (when the service becomes available 
>> again). I'm digging into the docs on how to accomplish this, but if you have 
>> some pointers I am open to suggestions.
>> 
>> 
>> Thanks,
>> Mike
>> 
>> 
>> On Apr 7, 2010, at 12:30 AM, Norman Maurer wrote:
>> 
>>> Hi Mike,
>>> 
>>> comments are inside..
>>> 
>>> 2010/4/6 Mike Dougherty <[email protected]>:
>>>> Hey all,
>>>> 
>>>> I'm using James as the front end for an email based app I am building. I 
>>>> have a couple questions about best practices and the design I've come up 
>>>> with.
>>>> 
>>>> The first question is in regard to user management. The app I've developed 
>>>> uses the recipient and sender extensively in its logic. So I need them in 
>>>> the app's database. However, at the same time, there are a few addresses 
>>>> which James will manage locally. I see at least 3 ways of accomplishing 
>>>> this.
>>>> 
>>>> 1. My app can create users in James' database (ether using RemoteManager 
>>>> or direct db inserts) as they get created in the application.
>>>> 2. My app can implement the LDAP protocol which James could use to check 
>>>> the recipient. The drawback here is that the addresses I want James to 
>>>> manage locally have to be in my apps database. Which sort of clutters up 
>>>> the data a bit.
>>> 
>>> What about writing a custom UsersRepository implementation ? So JAMES
>>> would lookup users directly "via your app" ?
>>> 
>>>> 3. If James can be configured to use wildcards (i.e. accept 
>>>> *[email protected]) then it can handle local addresses, and then hand off 
>>>> unknown addresses to a custom Mailet (or Repository).
>>> 
>>> Possible without problems
>>> 
>>>> 
>>>> #3 Seems the ideal solution. But it is contingent on James being able to 
>>>> accept wildcard addresses. As well as being configured to lookup local 
>>>> addresses, and failover to a custom Mailet.
>>>> 
>>> 
>>> See comments on 2, 3 ;)
>>> 
>>>> The second question I have is in regard to a Custom Mailet vs. a Custom 
>>>> Repository. As I mentioned all mail to a non-local user will be pushed 
>>>> onto my application. At first glance a custom Mailet seemed the best way 
>>>> to accomplish this. But now that I've dug into James a bit deeper, I'm 
>>>> wondering if writing a custom repository class would be a better option. 
>>>> Or would it even really matter?
>>> 
>>> This depends a bit on your need. What kind of stuff you need to
>>> forward to your app ? The Mail object, the MimeMessage or just some
>>> meta info ?
>>> 
>>>> 
>>>> The application I am building will have a lot of traffic. So I'm not 
>>>> concerned about the easiest solution from either a development or 
>>>> configuration perspective. I'm concerned about the most efficient (in both 
>>>> memory and processing for James) solution.
>>>> 
>>>> 
>>>> Thanks for you thoughts or comments.
>>>> Mike
>>>> 
>>>> 
>>>> 
>>>> **********************************
>>>>  Mike Dougherty
>>>>  858.232.3635
>>>>  [email protected]
>>>>  Mogiv, Inc.
>>>>  http://www.mogiv.com
>>>> **********************************
>>>> 
>>>> 
>>>> 
>>> 
>>> Bye,
>>> Norman
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>> 
>> 
>> **********************************
>>  Mike Dougherty
>>  858.232.3635
>>  [email protected]
>>  Mogiv, Inc.
>>  http://www.mogiv.com
>> **********************************
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

**********************************
 Mike Dougherty
 858.232.3635
 [email protected]
 Mogiv, Inc.
 http://www.mogiv.com
**********************************




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to