[ http://issues.apache.org/jira/browse/JAMES-482?page=comments#action_12375283 ]
Bernd Fondermann commented on JAMES-482: ---------------------------------------- it would be great to have a unit test reproducing this. > incorrect state on duplicate mail (LinearProcessor) > --------------------------------------------------- > > Key: JAMES-482 > URL: http://issues.apache.org/jira/browse/JAMES-482 > Project: James > Type: Bug > Components: SpoolManager & Processors > Reporter: Norman Maurer > Priority: Minor > > There is a bug in the LinearProcessor. When a Mail is duplicted because a > matcher has matched only some of the recipients, the state of the new mail > for the not matched recipients is not set correctly. > Imagine the following scenario: There is a processor which is not the root > processor. In this processor there is a matcher (let's call ist MatcherOne) > which matches only some on the recipients of a Mail. This is followed by a > matcher (let's call it MatcherTwo) which matches some or all of the > recipients which were not matched by MatcherOne. The Mailet for MatcherTwo > does not set the Mail's state. This is followed by more matcher-mailet-pairs. > The following ought to happen: When MatcherOne matches some of the > recipients, the Mail gets duplicated. The orginal instance is sent to the > mailet of MatcherOne. The duplicate for the not matched recipients is handed > to the next matcher: MatcherTwo. Let's say that MatcherTwo matches all > remaining recipients. Than the mailet of MatcherTwo is processed. Since this > mailet does not change the state, the next matcher in the current processor > should be used next. > What really happens because of the bug: When MatcherOne matches some of the > recipients, the Mail gets duplicated. The orginal instance is processed > correctly. The duplicate for the not matched recipients has the incorrect > state "root". Nevertheless, it is handed to the next matcher of the current > processor: MatcherTwo. Let's say that MatcherTwo matches all remaining > recipients. Then, the mailet of MatcherTwo is processed. This mailet does not > change the state, but the Mail is then treated as if that mailet had changed > the state to "root". Thus the whole processing chain starts over again. This > does not cause an endless loop, becauce when the Mail will reach the > processor where all this happened again, MatcherOne will match all remaining > recipients, so that no further duplication of the Mail will take place. The > Mail will than complete the processing chain. But some matchers and mailets > from before this point will have been called twice. In most cases, this might > remain unnoticed, but if those mailets do stuff like adding footers, those > footers are added twice. > Possible fixes: > Add > setState(mail.getState()); > to the constructor MailImpl(Mail,String) or add > notMail.setState(mail.getState()); > to the service method of LinearProcessor. > I don't know which fix might be preferrable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
