spring-projects/spring-integration-aws

WARN logs in default configuration

chrylis opened this issue · 6 comments

chrylis commented

I posted a question over at Stack Overflow about a log warning that appears in the default configuration for an SnsMessageHandler, and while there may be a way to configure around the warning, it seems to me that an out-of-the-box setup shouldn't produce reliable log noise like this. Would it be reasonable to add a built-in filter for nativeHeaders by name to prevent this problem? If so, should that go into the default value for AbstractMessageAttributesHeaderMapper#outboundHeaderNames or somewhere else?

artembilan commented

Sure!

We probably can improve that AbstractMessageAttributesHeaderMapper in this part of logic:

private volatile String[] outboundHeaderNames = {"!" + MessageHeaders.ID, "!" + MessageHeaders.TIMESTAMP,
			"!" + AwsHeaders.MESSAGE_ID, "!" + AwsHeaders.QUEUE, "!" + AwsHeaders.TOPIC, "*"};

excluding this NativeMessageHeaderAccessor.NATIVE_HEADERS or similar headers which might be populated upstream by some framework component.

If you have a set of those headers, feel free to open a PR with respective fix.

Thanks

chrylis commented

The default JsonObjectMapper inserts several type fields, and these can also cause warnings when using default transformers (which I'm not, because of other reasons). Should these be included in the filter?

chrylis commented

(As a note, this is one spot to mark for API improvement in 3.x. Having a String[] instead of a Collection<String> or even something more rules-like makes user overrides much more difficult.)

chrylis commented

I don't see a specific rule in the Spring Code Style regarding line wrapping "bullet lists". Is it permissible to wrap after each entry in outboundHeaderNames for readability?

artembilan commented

I think this whole change must go only to 3.0. Even just filtering that single header is a breaking change. Right, there is no such a rule - just follow a common sense to have it readable!
Thank you !