Package com.shri.restinpeace.reactor

Class MonoCallAdapterFactory

java.lang.Object
com.shri.restinpeace.reactor.MonoCallAdapterFactory
All Implemented Interfaces:
CallAdapterFactory
public final class MonoCallAdapterFactory extends Object implements CallAdapterFactory
Claims every Mono<T>-returning @RestClient method - Mono<Void>, Mono<RipResponse<T>>, and Mono<byte[]> all work identically, since responseBodyType() just names T verbatim and RequestExecutor's existing dispatch already handles every one of those shapes for any CallAdapter. See docs/design/reactor-call-adapter.md §6.

Eager, not deferred (§6.1): the method call that returns a Mono<T> has already dispatched the HTTP request by the time it returns - the same convention CompletableFuture<T> already follows elsewhere in RIP. Subscribing only observes the outcome; it never triggers the call. A consumer who wants Reactor's usual defer-until- subscribed semantics wraps it themselves: Mono.defer(() -> api.getUser(id)).

  • Constructor Details

    • MonoCallAdapterFactory

      public MonoCallAdapterFactory()

  • Method Details

    • get

      public Optional<CallAdapter<?>> get(Method method)
      A raw Mono (no type parameter) declines rather than throws - RequestExecutor.resolveCallAdapter(java.lang.reflect.Method) is called from ReflectiveRestClientValidator's own per-method validation loop too, which collects every problem via ValidationResult.addError(...) rather than throwing mid-loop (throwing here would abort validation for every other method on the same interface with an uncaught exception instead of a clean, collected error). Declining instead lets a raw Mono fall through to the existing KNOWN_UNSUPPORTED_REACTIVE_TYPES denylist check from chunk 2 - Mono.class's own fully-qualified name is already on that list - reporting it the same clean way an unclaimed Mono<T> already is.
      Specified by:
      get in interface CallAdapterFactory