You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@james.apache.org by GitBox <gi...@apache.org> on 2021/05/21 17:24:20 UTC
[GitHub] [james-project] chibenwa opened a new pull request #447: JAMES-3589 Reasonable tests regarding mailet container execution
chibenwa opened a new pull request #447:
URL: https://github.com/apache/james-project/pull/447
We expect:
- A mailet to be executed once for each recipients upon partial match and not several time
- A terminating mailet should not abort processing of previously split mails
- Mail modifications upon partial match should be retained
- After a partial match, downstream recipients should not be executed twice for a given recipient
The tests pass b replacing Camel logic by simple Java code:
```
public class CamelMailetProcessor extends AbstractStateMailetProcessor implements CamelContextAware {
private static final Logger LOGGER = LoggerFactory.getLogger(CamelMailetProcessor.class);
private final MetricFactory metricFactory;
private List<MatcherMailetPair> pairs;
public CamelMailetProcessor(MetricFactory metricFactory) {
this.metricFactory = metricFactory;
}
@override
public void service(Mail mail) throws MessagingException {
pairs.stream()
.reduce(ImmutableList.of(mail), (mails, pair) -> {
if (mails.size() > 0) {
return executePair(mails, pair);
}
return ImmutableList.of();
}, (a, b) -> {
throw new NotImplementedException("Fold left implementation. Should never be called.");
});
}
private ImmutableList<Mail> executePair(ImmutableList<Mail> mails, MatcherMailetPair pair) {
MatcherSplitter matcherSplitter = new MatcherSplitter(metricFactory, this, pair);
ImmutableList<Mail> afterMatching = mails.stream()
.flatMap(Throwing.<Mail, Stream<Mail>>function(mail -> matcherSplitter.split(mail).stream()).sneakyThrow())
.collect(Guavate.toImmutableList());
afterMatching
.stream().filter(mail -> mail.removeAttribute(MATCHER_MATCHED_ATTRIBUTE).isPresent())
.forEach(Throwing.<Mail>consumer(mail -> new CamelProcessor(metricFactory, this, pair.getMailet())
.processMail(mail)).sneakyThrow());
afterMatching.stream()
.filter(mail -> !mail.getState().equals(getState()))
.filter(mail -> !mail.getState().equals(Mail.GHOST))
.forEach(Throwing.consumer(this::toProcessor).sneakyThrow());
return afterMatching.stream()
.filter(mail -> mail.getState().equals(getState()))
.collect(Guavate.toImmutableList());
}
// Few boiler plate methods
}
```
Mail.duplicate does not copy state, matched mail is sent back to `root`
and mailet/matcher prior and at this stage are executed twice. Which feels
like 'unexpected'. This bug is present since at least 2015.
Preserving the state leads to other Camel related issues like lifecycle
management of the exchange, routing issues, etc... It looks like having two Mail flowing the same exchange had never been thought off. I did not win that battle.
To be fairly honnest my feeling is that:
- Camel had been used for some complicated integrations, via some tweaks of `spring configuration` to output emails to some tierce system and benefit for that of Camel ecosystem.
- The right way to do that would be to just write a Mailet.
- Camel brings in complexity, dependencies, the project apparently have an untested legacy regarding it, and do not have the knowledge.
- Camel is a blocker on the road to **reactive** mailets / matchers.
- I truly think we will be better off without it. And have a plain Java implementation of it.
Tomorrow...
- [ ] I will set up a Proof Of Concept PR for a plain Java mailetContainer
- [ ] I will continue to scratch my head at this Camel hell.
- [ ] I will probably contact Camel PMC
Cc @mbaechler @jeantil @rouazana
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org
[GitHub] [james-project] chibenwa merged pull request #447: JAMES-3589 Reasonable tests regarding mailet container execution
Posted by GitBox <gi...@apache.org>.
chibenwa merged pull request #447:
URL: https://github.com/apache/james-project/pull/447
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org
[GitHub] [james-project] chibenwa commented on pull request #447: JAMES-3589 Reasonable tests regarding mailet container execution
Posted by GitBox <gi...@apache.org>.
chibenwa commented on pull request #447:
URL: https://github.com/apache/james-project/pull/447#issuecomment-846350837
Force pushed. I spent my morning adding as much tests as I could think of.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org
[GitHub] [james-project] chibenwa commented on pull request #447: JAMES-3589 Reasonable tests regarding mailet container execution
Posted by GitBox <gi...@apache.org>.
chibenwa commented on pull request #447:
URL: https://github.com/apache/james-project/pull/447#issuecomment-850778462
(Just rebased to solve conflict)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org