Fixes #13 Previously the `@EnableRetry` caused to proxy **all** beans in the context, because of `IntroductionAdvisor` nature in the `AopUtils` logic and simple `ClassFilter.TRUE` in that case. In the end it just skipped `MethodMatcher` and applied `ProxyFactory` for any bean. Since we can't avoid `IntroductionAdvisor` because of `getInterfaces()` introduction, provide a new internal `AnnotationClassOrMethodFilter` to apply both class and method level annotation filter at once. Polishing for the `AnnotationAwareRetryOperationsInterceptor` to skip non-`@Retryable` methods and just call `invocation.proceed()` Fixes gh-13, fixes gh-14
* Add `RetryInterceptorBuilder` and its tests * Add usage from `AnnotationAwareRetryOperationsInterceptor` * Add `Retryable#interceptor()` option to use full Retry Interceptor from `BeanFactory` * Fix `RetryConfiguration` `beanFactory` propagation Fixes gh-11
* Deprecate `ObjectWaitSleeper` and replace it with `ThreadWaitSleeper` * Improve `SimpleMethodInvoker` * Use `if (logger.isDebugEnabled())` for better performance The `RetryTemplate` continues to invoke `canRetry(retryPolicy, context)` with retry loop, because some end application may rely on that logic. Although it looks like overhead to call `canRetry()` twice a retry: it might be heavy operation, e.g. check the state of external system Fixes gh-10
This is purely a marker interface, but might be useful for other tools looking to apply retry advice (they should usually not bother if the bean already implements Retryable)
So RetryCallback<T, E extends Throwable> and the E parameter appears in RetryOperations too, making it possible to call it with an unchecked exception type in the parameter and not catch exceptions. Users should beware: it's just syntactic sugar, and the actual runtime type of the exception is never checked at runtime. So, for instance, declaring a RetryCallback<Object,IllegalArgumentException> doesn't mean that other Exceptions won't be retried, just that you won't be able to explicitly throw them if they are checked. A project using Spring Batch 2.2 was used to test that this works with user code that uses a library compiled agains Spring Retry 1.0. Fixes gh-6
This allows use of spring-retry with naughty libraries that use Error conditions to signal retryable exceptions. Users can still declare their RetryCallback as "throws Exception" if they want to be conservative. Also added throwLastExceptionOnExhausted to RetryTemplate to throw the last exception instead of the ExhaustedRetryException.