There should be an additive option for decorating ExecutorServices, potentially outside the Factory

[simonbasle]

Libraries like Sleuth use the Schedulers.Factory to decorate the backing ScheduledExecutorService, rather than changing the Scheduler implementations themselves.

Now that we want to introduce a thin Micrometer instrumentation wrapper (#1201) that would work on the same ExecutorServices, it appears this can be problematic. It has also proven error-prone when user code captures a Scheduler before a library sets a Factory for the purpose of ExecutorService-wrapping, without actually touching the Schedulers, because setFactory always shuts down previous schedulers 😢 (see spring-cloud/spring-cloud-sleuth#866)

As a result, it would be far better to have Schedulers.addDecorator and Schedulers.removeDecorator type of methods, which would allow additive set up of ExecutorService decorators separately from the Scheduler Factory.

[simonbasle]

The current Supplier<ScheduledExecutorService> model doesn't work well with composition, but it had the additional benefit of hiding a sort of "metadata" in the toString() method of the suppliers => the Scheduler themselves are the Supplier and thus they define a rich toString() method. It would be good to add the notion of metadata to the new method in addition to the "Scheduler type" String.

[simonbasle]

proposed API: public static void addExecutorServiceDecorator(BiFunction<Tuple2<String, String>, ScheduledExecutorService, ScheduledExecutorService> decorator)

The legacy Factory decorateExecutorService would be deprecated, but still applied first when a Scheduler calls Schedulers.decorateExecutorService.

[simonbasle]

after discussing with @smaldini and @marcingrzejszczak, maybe a composite addFactory API would be better, and in any case keying the decorator with a String would be preferred vs keeping up with instances.

[madgnome]

As a consumer, I would indeed prefer working with String key than having to keep a BiFunction around.