Deprecate Message#getFormat()

[vy]

Message#getFormat() doesn't only have unclear semantics, it is also implemented very inconsistently. One might think it should return JSON by messages that want to format themselves in JSON, yet, thanks to many implementations forwarding getFormat() to message (yes, the arbitrary user-provided message!), this is not the case.

In short, it is an incomplete and failed attempt to allow messages to format themselves in one or more encodings. Good news is, we already have a working solution for that: MultiformatMessage.

This PR

1. deprecates Message#getFormat()
2. advocates MultiformatMessage

[ppkarwasz]

Looks good to me.

There are also other call sites of Message.getFormat() that we could deprecate: the useRawMessage attribute of RegexFilter does not make much sense, since it uses getFormat().

[vy]

the useRawMessage attribute of RegexFilter does not make much sense, since it uses getFormat().

This is a difficult one. That is, I can understand the rationale behind useRawMessage:

1. Efficiency (no need to format parameters)
2. Avoiding ambiguity – For instance, given logging statements LOGGER.info("foo {}", userProvidedField) and LOGGER.info("foo bar"), how can I only match the latter without using useRawMessage? That is, a malicious user can pass userProvidedField as bar.

In short, useRawMessage has value, but it is implemented incorrectly, IMO. Instead, I think, we should have introduced a RegexFilterableMessage contract and implement it in certain message types. Since this is rather a big undertaking, for the time being, I have improved RegexFilter in 33373f9 to specialize on certain message types. @ppkarwasz, is this okay with you?

[ppkarwasz]

In short, useRawMessage has value, but it is implemented incorrectly, IMO. Instead, I think, we should have introduced a RegexFilterableMessage contract and implement it in certain message types. Since this is rather a big undertaking, for the time being, I have improved RegexFilter in 33373f9 to specialize on certain message types. @ppkarwasz, is this okay with you?

I guess for now it is enough. We might want to add a RegexFilterableMessage (or StringFormatMessage or whatever the appropriate naming is) in the future, but we'd better discuss the new interface on dev@logging first. For the deprecation no discussion is necessary IMHO: the facts speak for themselves, the getFormat() method is not correctly defined.