search

failsafe-lib / failsafe

Fault tolerance and resilience patterns for the JVM
https://failsafe.dev
Apache License 2.0
4.17k stars 296 forks source link

Policy builders #299

Closed jhalterman closed 2 years ago

jhalterman commented 2 years ago

For 3.0, let's switch Failsafe to use builders and/or factory methods for constructing policies. This will allow all policy classes to remain hidden, and will allow us to have public and private interfaces for each policy implemented by the same policy class (ex: CircuitBreaker currently has two classes for this).

Tembrel commented 2 years ago

Any early thoughts on extensibility?

(Also: This is numerologically apt, being the last issue number before 300, and dealing with 3.0.0.)

jhalterman commented 2 years ago

Yes! We're on the verge of 300 - I hope it's a good one.

Any early thoughts on extensibility?

I've been working on a 2.5.0 branch (there are a few issues labeled 2.5.0 that should be resolved for that release) that includes some internal changes that improve async executions (ex: f12b90d6219646458f567787be79b3f13300373b), with one more large refactoring left to make the Policy SPI more easily extensible, per #292, for users who wish to create their own policies. Were you thinking about extensibility of existing policies, or something else?

Tembrel commented 2 years ago

I was hinting at #292, which gets a bit more challenging in the presence of builders. Or maybe that's a place to punt and just let user-defined policies have whatever construction method the definer deems best.

jhalterman commented 2 years ago

Yea, that's true. I don't have any good ideas at the moment for defining a standard way of building a policy. Thread safety would be the main thing a policy might want, though that's probably up to the implementer.

jhalterman commented 2 years ago

3.0 has been released, which includes this feature.