Allow Appenders and Handlers to pass a zero length message to network #96
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change allows both Appenders (org.apache.log4j.Appender) and Handlers
(java.util.logging.Handler) to send zero length and null messages to
a remote destination. Previously both zero length and null messages were
pruned out in GelfMessage class.
Though pruning out empty messages makes sense in terms of saving (some)
network traffic, it's kind of counterintuitive for several reasons.
To begin with, those who are familiar with other implementations expect
to see an empty message to get passed along. E.g. o.a.l.ConsoleAppender,
o.a.l.FileAppender, j.u.l.ConsoleHandler, and j.u.l.FileHandler all
allow a zero length/null message to be passed on.
Additionally, an Appender/Handler implementation is not supposed to
prune out any messages, besides invalid ones which simply can not be
passed due to missing information. In this case an empty message is
not something that prevents it being sent, as long as other GELF
parameters are all right. If additional filtering is needed, that should
go in org.apache.log4j.Filter or java.util.logging.Filter implementation
respectively.
Finally, there is a use case for sending empty messages as well. Some
developer might want to do log.info(thisStringIGotPassed), and should
the string be empty, it'd be reasonable to expect an empty log entry
appear, instead of receiving an error "Could not send GELF message".
References:
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Appender.html
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/spi/Filter.html
https://docs.oracle.com/javase/7/docs/api/java/util/logging/Filter.html
https://docs.oracle.com/javase/7/docs/api/java/util/logging/Handler.html