[ http://issues.apache.org/jira/browse/JAMES-482?page=comments#action_12375289 ]
Stefano Bagnara commented on JAMES-482: --------------------------------------- Look at the LinearProcessorTest I wrote to prove JAMES-421. I'm also not sure about the best of the 2 solutions. Fixing the "duplicator" constructor seems to me the cleaner way, but this could change how things works in other places of the code. We should probably review all the calls to that constructor and understand wether we need or not to keep the state. > 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]
