Fixes https://github.com/spring-projects/spring-retry/issues/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.
