GH-3096: Skip RESOLVABLE_TYPE header in mapping

[artembilan]

Fixes #3096

When we sent an AMQP message we should not map a
JsonHeaders.RESOLVABLE_TYPE header which is a ResolvableType and
isn not compatible after converting to string

Also improve JsonToObjectTransformer to ignore a
JsonHeaders.RESOLVABLE_TYPE when it is type of String

[garyrussell]

Travis failures.

Do we really want to just skip it? I see it is serializable - can we not just serialize it to a byte[] ?

[garyrussell]

But I guess that could be a new feature, different PR.

[artembilan]

Please, hold off the merge until #3100.
That is not a problem of this PR, but master is broken at the moment.

If you want I can @Ignore that test until we merge the mentioned PR and this one.

Thanks

[artembilan]

can we not just serialize it to a byte[]

I don't think it so platform independent to use Java serialization...

We may reconsider that in the future.
That ResolvableType header was never intended for sending over the network. I've missed that somehow...

[garyrussell]

Hmmm - I merged 3100 but still curious why travis failed here because this branch doesn't have

69401c263c33bffae54bc524ca396ef3944fe773 Back-pressure tests for SubscribableChPubAdapter

[artembilan]

Yeah... Have on idea. Have just rebased and force-pushed.

[garyrussell]

was never intended for sending over the network.

Then what is the purpose of setting the header in the first place? It's unlikely we convert to JSON and back to a POJO in the same app and I see the JTOT falls back to assembling it from the other headers.

I don't have a problem with this as-is; just curious.

[artembilan]

A JsonToObjectTransformer supports now public JsonToObjectTransformer(ResolvableType targetType, @Nullable JsonObjectMapper<?, ?> jsonObjectMapper) {
So, for consistency and flexibility in the integration flow we also rely on a header provided upstream.
It is not a fact that such a header might be build by the ObjectToJsonTransformer only: end-user may provide his/her own per message basis.

We can think, though, about reconstructing this header in the DefaultAmqpHeaderMapper similar way how it is done in the ObjectToJsonTransformer with that JsonObjectMapper.populateJavaTypes() call.

[garyrussell]

I have merged it, but perhaps we should add some protection here

ResolvableType valueType = headers.get(JsonHeaders.RESOLVABLE_TYPE, ResolvableType.class);

and ignore if it's the wrong type?

[artembilan]

I thought I did in the JsonToObjectTransformer:

return valueType instanceof ResolvableType
				? (ResolvableType) valueType
				: null;

[garyrussell]

Sorry - I was looking locally without pulling 😦

[artembilan]

Some clean up commit though: dd1d65b