I'm using DSL and Lambdas with the Spring Integration library and running into a weird issue.
I attempted to build an IntegrationFlow that would split file data at the newline character. When I had the lambda expression inline to the builder it worked fine:
return IntegrationFlows.from(this.inboundStreamingMessageSource())
.transform(new StreamTransformer("UTF-8"))
.split(s->s.applySequence(true).get().getT2().setDelimiters("\n"))
In the above example the split method is receiving a Consumer of SplitterEndpointSpec. At that point I factored out the lambda into its own Field for readability:
return IntegrationFlows.from(this.inboundStreamingMessageSource())
.transform(new StreamTransformer("UTF-8"))
.split(NewlineSplitter)
...
final Consumer<SplitterEndpointSpec<DefaultMessageSplitter>> NewlineSplitter =
s -> s.applySequence(true).get().getT2().setDelimiters("\n");
However, I get a stacktrace exception running this. Currently its:
org.springframework.messaging.MessageHandlingException: nested exception is java.lang.IllegalArgumentException: No candidate methods found for messages
At another time, I got a Classcast exception stating that the type String.class could not be converted to SplitterEndpointSpec. If you look at the API documentation for the IntegrationFlowDefinition that I'm calling split
from, you can see that the method is heavily shadowed: there are about 12 variations of differing parameter lengths. Is the compiler misinterpreting which version of split I'm calling?
I simply cannot see what would cause this behavior and am unsure if this is a Java 8 error or a problem with the Spring-integration implementation. I am using spring-integration-dsl 1.2.3.RELEASE and am probably stuck with that version at the moment due to the dependencies defined in another library built for it.
First of all you don't need to exercise that get().getT2().setDelimiters("\n")
- there is already a delimiters()
option on the SplitterEndpointSpec
:
s.applySequence(true).delimiters("\n")
Secondly it looks more like an issue of the compiler you use. Have just tested your use-case with the:
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
Works well without any complains and runtime errors.
On the other hand I use the latest Spring Integration. How about you? What version is in use?