Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Appenders and Handlers to pass a zero length message to network #96

Merged
merged 1 commit into from Feb 1, 2016
Merged

Allow Appenders and Handlers to pass a zero length message to network #96

merged 1 commit into from Feb 1, 2016

Conversation

ghost
Copy link

@ghost ghost commented Feb 1, 2016

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

…dlers

(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
@t0xa
Copy link
Owner

t0xa commented Feb 1, 2016

Hi @samilaine,

I appreciate the effort you put in this pull request. It's a great example of how collaboration should be done!

Thank you.

t0xa added a commit that referenced this pull request Feb 1, 2016
Allow Appenders and Handlers to pass a zero length message to network
@t0xa t0xa merged commit 9ca20b7 into t0xa:master Feb 1, 2016
@ghost ghost deleted the zerolenmsgs branch February 2, 2016 15:58
@t0xa
Copy link
Owner

t0xa commented Feb 3, 2016

Hi @samilaine,

Version 1.1.14 with your pull request released.
Thanks again for your help.

Anton

@ghost
Copy link
Author

ghost commented Feb 9, 2016

The pleasure was all mine. Thank you for putting Gelfj together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants