Make some internal APIs more open

[timothybasanov]

Not a Contribution.

Currently a lot of internal APIs are well, internal. It should be possible to implement a different Timeout or Retry policy from an application package. This may require to make some package local methods and classes to be public.

[timothybasanov]

Not a contribution.

One example, it should be possible to implement Support staggered retries #291 or Considering allowing a Future result to be completed immediately when a Timeout occurs #231 using open APIs.

[jhalterman]

Sure, the goal is to make protected or public anything that needs to be to extend Failsafe while guarding the rest. Are there specific methods/fields/classes you'd like to see by made protected or public?

[timothybasanov]

Not a contribution.

Yep, all the methods and classes currently referenced from a timeout or retry policies and executions (e.g. an abstract execution's methods, a timeout execution itself). A test for this would be a custom timeout or retry policy in a different package that adjust existing ones a bit.

[jhalterman]

@timothybasanov I just pushed a big refactoring to the master branch to support a more proper SPI, where the various internals are exposed and creating custom policies should be more possible now. Have a look and please let me know what you think. I'd like to release this for 2.5.0 soon.

Most of the interesting things for you are now in the spi package. This is where PolicyExecutor now lives, which uses new ExecutionInternal, SyncExecutionInternal, and AsyncExecutionInternal interfaces for internal common, internal sync, and internal async execution behaviors respectively. Let me know how this looks and if I'm missing anything.

[jhalterman]

This issue auto-closed since I just merged the related changes to master. @timothybasanov let me know what you think if you can soon. Would be good before I make a 2.5 release.