Closed jhalterman closed 3 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.)
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?
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.
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.
3.0 has been released, which includes this feature.
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).