我正在将int:request-handler-advice-chain与我的服务激活器一起使用。它与org.springframework.retry.policy.SimpleRetryPolicy一起正常工作，但是我想根据服务激活器抛出的异常，使用org.springframework.retry.policy.ExceptionClassifierRetryPolicy允许不同数量的重试。
我遇到的问题是，当异常到达ExceptionClassifierRetryPolicy时，这是一个
org.springframework.integration.MessageHandlingException
任何人都可以就从MessageHandlingException提供给ExceptionClassifierRetryPolicy的原因（即我的例外）的最佳方法提出建议吗？
由于Artem的建议，解决方案如下：
创建SubclassClassifier的子类，该子类在MessagingException的情况下返回原因
public class MessagingCauseExtractingSubclassClassifier extends SubclassClassifier<Throwable, RetryPolicy> {
private static final Logger LOG = LoggerFactory.getLogger(MessagingCauseExtractingSubclassClassifier.class);
public MessagingCauseExtractingSubclassClassifier(final Map<Class<? extends Throwable>, RetryPolicy> policyMap, final RetryPolicy retryPolicy) {
super(policyMap, retryPolicy);
}
@Override
public RetryPolicy classify(final Throwable throwable) {
Throwable t = throwable;
if (t instanceof MessagingException) {
t = t.getCause();
LOG.debug("Throwable is instanceof MessagingException so classifying cause type: {}", t.getClass());
}
return super.classify(t);
}
}
然后是一个新的ExceptionClassifierRetryPolicy子类，它使用新的分类器和policyMap
public class MessasgeCauseExtractingExceptionClassifierRetryPolicy extends ExceptionClassifierRetryPolicy {
@Override
public void setPolicyMap(final Map<Class<? extends Throwable>, RetryPolicy> policyMap) {
final MessagingCauseExtractingSubclassClassifier classifier = new MessagingCauseExtractingSubclassClassifier(
policyMap, new NeverRetryPolicy());
setExceptionClassifier(classifier);
}
}
当前，这将不支持在MessagingException上重新输入，但是这对于我们的用例是很好的。否则，效果很好。
最佳答案
BinaryExceptionClassifier具有traverseCauses选项以分析整个StackTrace，直到达到适当的条件为止。
正是这个选项与SimpleRetryPolicy构造函数之一一起使用：
public SimpleRetryPolicy(int maxAttempts, Map<Class<? extends Throwable>, Boolean> retryableExceptions,
boolean traverseCauses) {
请查看该变体对您是否可行。