You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Paul D Johe (JIRA)" <ji...@apache.org> on 2015/03/05 12:58:38 UTC

[jira] [Comment Edited] (LOG4J2-969) Refactor syslogappender so that Layout is an PluginElement

    [ https://issues.apache.org/jira/browse/LOG4J2-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14348571#comment-14348571 ] 

Paul D Johe edited comment on LOG4J2-969 at 3/5/15 11:57 AM:
-------------------------------------------------------------

Sure, there are pattern converters that may break the message part of the BSD format, but then that would be an incorrect usage of the pattern; the Log4j2 team doesn't need to try and fix the users of log4j2's coding mistakes. 

For us, we want to implement RFC3164 point 4.1.3:
{quote}
   The MSG part has two fields known as the TAG field and the CONTENT
   field.  The value in the TAG field will be the name of the program or
   process that generated the message.  The CONTENT contains the details
   of the message.  This has traditionally been a freeform message that
   gives some detailed information of the event.  The TAG is a string of
   ABNF alphanumeric characters that MUST NOT exceed 32 characters.  Any
   non-alphanumeric character will terminate the TAG field and will be
   assumed to be the starting character of the CONTENT field.  Most
   commonly, the first character of the CONTENT field that signifies the
   conclusion of the TAG field has been seen to be the left square
   bracket character ("["), a colon character (":"), or a space
   character.  This is explained in more detail in Section 5.3.
{quote}

This TAG could be thread context data, implemented using a simple PatternLayout on the message part of the BSD message. Or it could be a @PluginAttribute. With the log4j2 plugin system, this should really be easy to do...

...and you are right...it is easy to do, and I was just on the wrong track: we can simply use SocketAppender instead together with our own BsdSyslogLayout to solve our needs. Thank you for the tip! Maybe add to the log4j2 SyslogAppender documentation that the following are equivalent:

|{code}
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" name="MyApp" packages="">
  <Appenders>
    <Syslog name="bsd" host="localhost" port="514" protocol="TCP"/>
    <Syslog name="RFC5424" format="RFC5424" host="localhost" port="8514"
            protocol="TCP" appName="MyApp" includeMDC="true"
            facility="LOCAL0" enterpriseNumber="18060" newLine="true"
            messageId="Audit" id="App"/>
  </Appenders>
  <Loggers>
    <Logger name="com.mycorp" level="error">
      <AppenderRef ref="RFC5424"/>
    </Logger>
    <Root level="error">
      <AppenderRef ref="bsd"/>
    </Root>
  </Loggers>
</Configuration>
{code}|{code}
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" name="MyApp" packages="">
  <Appenders>
    <Socket name="bsd" host="localhost" port="514" protocol="TCP">
        <SyslogLayout />
    </Socket>
    <Socket name="RFC5424" host="localhost" port="8514" protocol="TCP">
        <Rfc5424Layout appName="MyApp" includeMDC="true"
            facility="LOCAL0" enterpriseNumber="18060" newLine="true"
            messageId="Audit" id="App"/>
    </Socket>
  </Appenders>
  <Loggers>
    <Logger name="com.mycorp" level="error">
      <AppenderRef ref="RFC5424"/>
    </Logger>
    <Root level="error">
      <AppenderRef ref="bsd"/>
    </Root>
  </Loggers>
</Configuration>
{code}|


Any chance of at least removing the 'final' modifier from all of log4j2 layout classes so that they can at least be extended? :-)


was (Author: pdjohe):
Sure, there are pattern converters that may break the message part of the BSD format, but then that would be an incorrect usage of the pattern; the Log4j2 team doesn't need to try and fix the users of log4j2's coding mistakes. 

For us, we want to implement RFC3164 point 4.1.3:
{quote}
   The MSG part has two fields known as the TAG field and the CONTENT
   field.  The value in the TAG field will be the name of the program or
   process that generated the message.  The CONTENT contains the details
   of the message.  This has traditionally been a freeform message that
   gives some detailed information of the event.  The TAG is a string of
   ABNF alphanumeric characters that MUST NOT exceed 32 characters.  Any
   non-alphanumeric character will terminate the TAG field and will be
   assumed to be the starting character of the CONTENT field.  Most
   commonly, the first character of the CONTENT field that signifies the
   conclusion of the TAG field has been seen to be the left square
   bracket character ("["), a colon character (":"), or a space
   character.  This is explained in more detail in Section 5.3.
{quote}

This TAG and pid could be thread context data, implemented using a simple PatternLayout on the message part of the BSD message. Or they could be @PluginAttributes. With the log4j2 plugin system, this should really be easy to do...

...and you are right...it is easy to do, and I was just on the wrong track: we can simply use SocketAppender instead together with our own BsdSyslogLayout to solve our needs. Thank you for the tip! Maybe add to the log4j2 SyslogAppender documentation that the following are equivalent:

|{code}
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" name="MyApp" packages="">
  <Appenders>
    <Syslog name="bsd" host="localhost" port="514" protocol="TCP"/>
    <Syslog name="RFC5424" format="RFC5424" host="localhost" port="8514"
            protocol="TCP" appName="MyApp" includeMDC="true"
            facility="LOCAL0" enterpriseNumber="18060" newLine="true"
            messageId="Audit" id="App"/>
  </Appenders>
  <Loggers>
    <Logger name="com.mycorp" level="error">
      <AppenderRef ref="RFC5424"/>
    </Logger>
    <Root level="error">
      <AppenderRef ref="bsd"/>
    </Root>
  </Loggers>
</Configuration>
{code}|{code}
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" name="MyApp" packages="">
  <Appenders>
    <Socket name="bsd" host="localhost" port="514" protocol="TCP">
        <SyslogLayout />
    </Socket>
    <Socket name="RFC5424" host="localhost" port="8514" protocol="TCP">
        <Rfc5424Layout appName="MyApp" includeMDC="true"
            facility="LOCAL0" enterpriseNumber="18060" newLine="true"
            messageId="Audit" id="App"/>
    </Socket>
  </Appenders>
  <Loggers>
    <Logger name="com.mycorp" level="error">
      <AppenderRef ref="RFC5424"/>
    </Logger>
    <Root level="error">
      <AppenderRef ref="bsd"/>
    </Root>
  </Loggers>
</Configuration>
{code}|


Any chance of at least removing the 'final' modifier from all of log4j2 layout classes so that they can at least be extended? :-)

> Refactor syslogappender so that Layout is an PluginElement
> ----------------------------------------------------------
>
>                 Key: LOG4J2-969
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-969
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Appenders, Layouts
>    Affects Versions: 2.2
>            Reporter: Paul D Johe
>              Labels: syslog, syslogappender
>
> There are quite a lot of attributes to the syslogappender that could have been simply included as:
> {code}
> @PluginElement("layout") Layout<? extends Serializable> layout,
> {code}
> This is much more flexible (for example, extension of existing syslog layouts) and the field 'format' becomes superfluous, as it is implied by the layout chosen (normally SyslogLayout or Rfc5424Layout will be chosen).
> Furthermore, it becomes much clearer which attributes are for the RFC5424 format and which are for the BSD format.
> Or at least add the possibility for a Layout element, which if does not exist will use the existing code. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org