Hi Norman,
if you prefer to work on the SPF side I can write the test and check
what the best fix is for this issue.
Let me know, so we don't work on the same issue :-)
Stefano
Stefano Bagnara (JIRA) wrote:
[ 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 un
noticed, 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
