Feature Description
Due to the shift to the MessageStream, we are inclined to unwrap all results from @MessageHandler annotated methods into MessageStreams.
Although most cases work, whenever we're faced with several layers of generics we hit predicaments.
There are roughly two scenarios of this that are annoying, which I'll explain shortly:
Single-entry MessageStream result while it should be a multi-entry variant
If a @QueryHandler annotated method returns the following, conversion exceptions will be thrown:
// Test example from the FutureAsResponseTypeToQueryHandlersTest class
@QueryHandler(queryName = "myQueryWithMultipleResponses")
public CompletableFuture<List<String>> queryHandler(String criteria) {
CompletableFuture<List<String>> completableFuture = new CompletableFuture<>();
executor.schedule(() -> completableFuture.complete(asList("Response1", "Response2")),
FUTURE_RESOLVING_TIMEOUT,
TimeUnit.MILLISECONDS);
return completableFuture;
}This has to do with the fact that the current behavior spots a CompletableFuture, assuming a single entry MessageStream will suffices. Whereas in fact, we are dealing with a collection and thus a multi-entry MessageStream should be returned.
Wrapping a Message in another Message
If a @QueryHandler annotated method returns the following, unexpected Message#payload outcomes will be returned:
@QueryHandler
public Mono<Message> queryHandler(String criteria) {
return Mono.just(new GenericMessage(new MessageType("my-response"), "response));
}This has to do with how the MessageStreamResolverUtils currently maps the contained object.
If a Mono/Flux/CompletableFuture/etc is given, we assume the contained object to not be a Message.
By simply checking if that's a Message instance, we can deal with this differently.
Given these are edge cases for annotated query handlers, we have marked this work to be resolved later. We do not deem supporting this to incur breaking changes to any APIs.
When picking up this issue, be sure to resolve any todos referring to this issue's issue number.
Current Behaviour
Message handlers returning responses with several generics deep may not get resolved to the expected MessageStream.
Wanted Behaviour
Message handlers returning responses with several generics deep are resolved to the expected MessageStream.
Possible Workarounds
Not use query handlers with several generics deep.
Feature Description
Due to the shift to the
MessageStream, we are inclined to unwrap all results from@MessageHandlerannotated methods intoMessageStreams.Although most cases work, whenever we're faced with several layers of generics we hit predicaments.
There are roughly two scenarios of this that are annoying, which I'll explain shortly:
Single-entry MessageStream result while it should be a multi-entry variant
If a
@QueryHandlerannotated method returns the following, conversion exceptions will be thrown:This has to do with the fact that the current behavior spots a
CompletableFuture, assuming a single entryMessageStreamwill suffices. Whereas in fact, we are dealing with a collection and thus a multi-entryMessageStreamshould be returned.Wrapping a
Messagein anotherMessageIf a
@QueryHandlerannotated method returns the following, unexpectedMessage#payloadoutcomes will be returned:This has to do with how the
MessageStreamResolverUtilscurrently maps the contained object.If a
Mono/Flux/CompletableFuture/etc is given, we assume the contained object to not be aMessage.By simply checking if that's a
Messageinstance, we can deal with this differently.Given these are edge cases for annotated query handlers, we have marked this work to be resolved later. We do not deem supporting this to incur breaking changes to any APIs.
When picking up this issue, be sure to resolve any todos referring to this issue's issue number.
Current Behaviour
Message handlers returning responses with several generics deep may not get resolved to the expected
MessageStream.Wanted Behaviour
Message handlers returning responses with several generics deep are resolved to the expected
MessageStream.Possible Workarounds
Not use query handlers with several generics deep.