IllegalArgumentException when using --mode=ref about file HOT 9 CLOSED

@sabbyanandan ,

The MessageConverterConfigurer has a logic like:

final BindingProperties bindingProperties = this.channelBindingServiceProperties.getBindingProperties(
				channelName);
final String contentType = bindingProperties.getContentType();
if (!input && bindingProperties.getProducer() != null && bindingProperties.getProducer().isPartitioned()) {
	messageChannel.addInterceptor(new PartitioningInterceptor(bindingProperties));
}
if (StringUtils.hasText(contentType)) {
	messageChannel.addInterceptor(new ContentTypeConvertingInterceptor(contentType, input));
}

So, if there is some contentType property configured for the binding that looks like it tries to convert the File payload to the expected contentType and fails with the null.

So, share, please, which binder properties you have for the file source.

from file.

Thanks for looking into this, @artembilan. I'm using rabbit-app with all the default configs. The latest rabbit-apps can be found here.

from file.

M-m-m. That doesn't help.
Sorry.
Look, I did this in the test-case for mode=ref:

"spring.cloud.stream.bindings.output.contentType=text/plain"

And voila! I ended up with the same IllegalArgumentException: payload must not be null, just because StringMessageConverter can't convert File object to the String via:

if (this.provideHint) {
	converted = ((AbstractMessageConverter) this.messageConverter).toMessage(message.getPayload(),
			new MutableMessageHeaders(message.getHeaders()), this.mimeType);
}

That must be fixed, but on the SCSt side.
I assume the simple fallback to the message.getPayload() should be enough in the end if we can't convert it to the expected contentType.

The file source isn't guilty.

from file.

This is a known issue with the MessageConverterConfigurer - if message conversion fails, it tries to create a message with a null payload; it should detect the converter returns null and throw a more meaningful error.

We added code to SI to permit suppressing the propagation of an inbound contentType to the outbound side; this looks like another flavor of that.

It seems to me that the "canConvert" test should be based on the payload type, not the contentType header (or fall back to the payload type if it finds the contentType is not convertible).

@mbogoevici ??

from file.

@garyrussell ,

???

It is file source: there is no inbound headers.
See my comment: #2 (comment). The contentType comes from the binder configuration.
We select the target converter based on that option.
And than we fail here because File doesn't meet StringMessageConverter requirements:

@Override
protected boolean supports(Class<?> clazz) {
	return (String.class == clazz);
}

from file.

I was just pointing out the flaw in the converter; I wasn't commenting on the origin of the contentType that was used for the conversion.

That's what I meant by "another flavor".

from file.

As per our IPM discussion, this is a SCSt regression. Looks like we have lost the ability to do simple Object->String conversions. StringMessageConverter won't work because it's specifically focused on String to byte[] (internal/wire format) conversions with a given encoding (i.e. when the attached contentType is text/plain).

My suggestion would be to:

a) as per @garyrussell 's suggestion, throw an exception when conversion fails instead of returning null

b) Include a unidirectional ObjectToString converter that can handle any non-String to outbound String (via payload.toString()) - it would be unidirectional, because there's no generic way to convert an inbound String to an POJO. cc/@artembilan

from file.

Basically this is what I think that we're missing: https://github.com/spring-cloud/spring-cloud-stream/blob/1.0.x/spring-cloud-stream/src/main/java/org/springframework/cloud/stream/converter/PojoToStringMessageConverter.java

Possibly a more enhanced version that can use encoding.

from file.

The fix in SCSt has been merged.
Local testing confirms it.
This issue should be addressed with an additional test-case when an appropriate SCSt version is picked up by app-starters-code.

from file.