https://issues.apache.org/bugzilla/show_bug.cgi?id=46626

--- Comment #4 from Steven Willis <[email protected]> ---
Regarding the TAG being part of the HEADER or MSG. That RFC definitely says
that the TAG is part of the MSG. However, there are some issues with that RFC
and syslog messages in general. I would highly recommend reading this write up:

http://www.rsyslog.com/doc/syslog_parsing.html

Notably: 'The syslog protocol has not been standardized until relatively
recently. The first document "smelling" a bit like a standard is RFC 3164,
which dates back to August 2001. The problem is that this document is no real
standard. It has assigned "informational" status by the IETF which means it
provides some hopefully useful information but does not demand anything. It is
impossible to "comply" to an informational document.'

And in future RFCs covering syslog messages, for example:
http://tools.ietf.org/html/rfc5424 the TAG (now called APP-NAME) field has been
moved into the header. Because, frankly, it makes more sense there.

The problem is that when a stack trace is sent along with a log message, the
SyslogAppender sends each line of the stack trace as a separate syslog message
and only prepends the HEADER. It doesn't send the line through the layout
formatter first. I was originally using the layout format to put my TAG at the
beginning of each log message, but since the stack trace lines don't go through
the formatter they weren't getting my TAG.

Also, with or without a TAG, the messages written by the updated class are
still compliant with rfc3164.

And about the TAG not exceeding 32 alphanumeric characters. I can update the
patch to deal with that. What would be the preferred behavior? I was thinking
of dealing with it inside setTag(String): silently truncate to 32 characters,
then throw an exception if any non-alphanum characters are found in the
remaining string.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to