Allow for non-void method calls in outbound channel adapter expression [INT-3815]
Mauro Molinari opened INT-3815 and commented
Right now, the SpEL expression I specify on an <int:outbound-channel-adapter> requires a void-returning expression, otherwise an exception is thrown.
However, this is limiting. What if I just want to call a method and ignore its return value?
In my case, I have a flow that ends in an outbound adapter that should just delete a temporary file. However File.delete() returns a boolean value, which I'm not interested in. Hence, an expression like payload.file.delete() throws a ConversionNotSupportedException, so now I have to wrap that expression into a ad-hoc service method call.
Is there a strong reason for requiring a void returning expression?
Affects: 4.1.6
Gary Russell commented
It's always been that way; an outbound adapter is a one-way integration with no possibility of a reply.
We might consider such a change, if there was some compelling reason to do so, but not this close to a release (the 4.2 release candidate is out already).
The generally accepted mechanism to do what you need is to terminate the flow with a <service-activator ... expression="payload.delete()"/> instead of an <outbound-channel-adapter/>, and set output-channel="nullChannel" which discards the reply.
Mauro Molinari commented
Hi Gary,
yes, of course it can be done with a service activator, but it's more work. When you talk about a "one-way integration with no possibility of a reply", it's exactly what I want, simply it's an implementation detail the fact that the method I'm calling through an expression returns something I don't care of. I haven't tried it, but it would be interesting to know what happens if I call a non-void method from the outbound channel adapter using ref/method instead of expression... would it throw an exception as well?
Gary Russell commented
Yes, it's not allowed there either; see MethodInvokingMessageHandler.
but it's more work
I don't think adding output-channel="nullChannel" to the service activator is particularly burdensome.
Mauro Molinari commented
You're in any case adding more "noise". I also feel like it's more of a stretching the use of a nullChannel-connected service activator to actually model a terminal node, rather than the use of an outbound channel adapter to invoke a method whose return value should simply be discarded.
Anyway, feel free to discard my request (like I discard the return value of File.delete() :D :D :P), this was just my suggestion. After all, the contract of an outbound channel adapter is clear, so I don't think that allowing a non-void method call by throwing away its result would be a surprise to the user. IMHO the current behaviour is just uselessly limiting.
Gary Russell commented
I am not saying I completely disagree; after all you can call a value-returning method from java and discard the result.
I am just saying we can't make a change like this in 4.2; especially since there's a reasonable work-around.
I've put this on the backlog and we can consider it for a future release.