> > IMHO the DEFAULT behaviour should be the deep copy.
>
> I disagree, what we're trying to do is to manage routing the message.
>
> Message can be routed down two different routes to its
> destination, but is still the same message.
-1 on that!
James developers already did mistakes due to mimemessage shared and this bug
report is the proof.
Performance can be achieved with copyonwrite proxies or different approach
but we should avoid that mailet writer run a mail.duplicate() and without
the knowledge that it will share the mimemessage.
NOONE will ever understand that running a matcher in a processor will
duplicate the envelope but will share the mimemessage so if you change one
of the 2 mails you don't know wether you will receive 2 identical messages
or 2 different ones!
> The default should be the least resource intensive.
The default should be the SAFEST. The unsafe optimization should be applied
understanding possible problems of the optimization.
As I already said we can achieve optimization later or in a different way
but first we should ensure that message handling is consistent and SAFE.
> In fact I would tend to say that the issue is not technical,
> but one of documentation. The docs should clearly explain
> that and any changes should be made only to ensure that there
> is a simple and consistent method which can be used to branch
> the message itself.
Please reread the bug report and not only the subject.
The issue is REAL and is a critical BUG: if you think that MimeMessage
sharing is good then it is a bug in the LinearProcessor.
I don't care wether the message is shared or not, but the scenario I
submitted should not give that result.
The developer that wrote the LinearProcessor did not consider that the
MailImpl.duplicate was returning a new Mail with the same MimeMessage.
The developer that wrote the AbstractRedirect did the bugfree thing (clone
the mimemessage).
This is the "easy" code that should be documented to do the right thing:
----
newMail.setMessage(new MimeMessage(originalMail.getMessage()) {
protected void updateHeaders() throws MessagingException
{
if (getMessageID() == null) super.updateHeaders();
else {
modified = false;
}
}
});
----
IMHO adding a copyonwrite proxy over the MimeMessageWrapper we can remove
also the deepcopy in the abstractRedirect and achieve better performance
than now, btw I don't care how we decide to fix it. I just want it to be
fixed.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
