Stefano,
You are *absolutely* correct! The Mail attributes get persisted and remain
intact when the message is re-delivered. There was some other exception I
was getting that was wiping them out... long story :)
Anyway, I have changed my process to use the Mail attributes now, and it
seems to work. I need to do some more testing & clean up the code. After
that, as per your suggestion, I will create a JIRA and attach the code for
your review.
Thanks (a lot) for your help with this.
- Ajay
On Thu, Aug 28, 2008 at 2:13 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Ajay Chitre ha scritto:
>
> I got busy with other issues, so I didn't get time to look at this for a
>> while.
>>
>> Anyway, as per Stefano's suggestion I started from RemoteDelivery and I am
>> able to use most of the relevant code; but our 'process' logic is a bit
>> different. This is what we would like to do:
>>
>> 1) We have a special processor "xyz" that uses 3 Mailets to do some
>> business logic. The "root" processor sends the message "ToProcessor" xyz.
>> 2) These 3 Mailets 'onMailetException' forward the mail to the new
>> "retry"
>> processor.
>> 3) The RetryMailet of the "retry" processor, writes the message to a
>> "retry" spool (similar to 'outgoing').
>> 4) When the Thread wakes up, it calls 'process(Mail)'. Everything works
>> well upto this point. But here's what we want to do in the 'process'
>> method:
>>
>> If (Max Retry count hasn't reached)
>> Send the Mail back to the "xyz" processor for re-processing
>> Else
>> Send the Mail to the "error" processor, which will "Bounce"
>>
>>
>> To implement this, I am trying this:
>>
>> if (retries < maxRetries) {
>> mail.setState("xyz");
>> } else {
>> mail.setState(Mail.ERROR);
>> }
>>
>> // re-insert the mail into the spool
>> MailetContext mc = getMailetContext();
>> try {
>> mc.sendMail(mail);
>> } catch (MessagingException e) {
>> // we shouldn't get an exception, because the mail was already
>> processed
>> log("Exception re-inserting failed mail: ", e);
>> return false;
>> }
>>
>> Thinking that the Mail object will have all the attributes intact when the
>> "xyz" processor is called. Unfortunately, nothing (apparent) happens.
>> When
>> I tried mail.setState(Mail.DEFAULT), the control goes to the "root"
>> processor, which forwards to our "xyz" - but all the Mail attributes are
>> gone, resulting in a loop.
>>
>
> What does exactly 'forwards to our "xyz"' means? Maybe the way you use to
> move the message simply loose mail attributes.
>
> What is the attribute being lost?
> Can you check if the attribute is there in the root processor?
>
> Anyway, I am debugging thru the James code, but if someone can tell me if
>> there's a better way to do this, that would be appreciated. Thanks.
>>
>
> The way you do things seems fine.
> Maybe you want to open a JIRA issue for this feature and attach your code
> so that I can better review the code instead of trying to understand from
> descriptions ;-)
>
> PS: Obviously, the other approach is to refactor our code such that we
>> don't
>> have to send it back to "xyz" processor and instead do what RemoteDelivery
>> is doing, but that's our last resort - cause that requires a lot of
>> refactoring of combining 3 Mailets into one.
>>
>
> There are many ways to duplicate a Mail object.
> The only one that should duplicate attributes is new MailImpl(oldmail,
> "newname") or oldmail.duplicate().
>
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
