logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1578) RoutingAppender can be configured with scripts
Date Wed, 14 Sep 2016 03:41:20 GMT

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

Ralph Goers commented on LOG4J2-1578:

EventLogger should not be a problem. If Log4j is part of the app's class loader then it will
go away along with the app. If it is in a parent class loader then it will hang around even
though the app goes away. That would all be working as expected.  Your problem here is that
you are cleaning up a LoggerContext but the classes attached to the class loader aren't going
away. That should only happen in unit tests. Remember, it is normal practice for applications
to declare their loggers as being static.

> RoutingAppender can be configured with scripts
> ----------------------------------------------
>                 Key: LOG4J2-1578
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1578
>             Project: Log4j 2
>          Issue Type: New Feature
>            Reporter: Gary Gregory
>            Assignee: Gary Gregory
> RoutingAppender can be configured with scripts. 
> h2. Use Case
> What I need to do is only add a specific appender when running on a specific OS (USS
on OS/390 if you must know). Then only add a different appender when not running on that OS.
> h2. Solution
> Posted by [~ralphgoers] on the dev ML:
> After reviewing what I wrote below and looking at the Routing Appender I think the best
thing to do is just to add script support to it.  It already has support for a default Route.
The init script, if present, could override which Route to use as I described below. Then
we could add a script attribute to the Routes plugin which could be used to select the Route
instead of only matching on the ThreadContext key.
> With that I think you would have everything you want, plus it could be used as a more
intelligent way to route to existing appenders.
> The configuration would then look like:
> {code:xml}
>   <Appenders>
>     <Console name="STDOUT" target="SYSTEM_OUT">
>       <PatternLayout pattern="%m%n"/>
>     </Console>
>     <Flume name="AuditLogger" compress="true">
>       <Agent host="" port="8800"/>
>       <Agent host="" port="8800"/>
>       <RFC5424Layout enterpriseNumber="18060" includeMDC="true" appName="MyApp"/>
>     </Flume>
>     <Routing name="Routing">
>       <InitScript name="RoutingInit" language="groovy"><![CDATA[
>          if (System.getProperty(?os.name?).contains(?OS/390") {
>             return "OS390";
>          }
>          return null;]]>
>       </InitScript>
>       <Routes>     
>         <Script name="Router" language="groovy"><![CDATA[
>             if (logEvent.getMarker() != null && logEvent.getMarker().isInstanceOf("AUDIT"))
>                 return "AUDIT";
>             } else if (logEvent.getContextMap().containsKey("UserId")) { 
>                 return logEvent.getContextMap().get("UserId");
>             }
>             return "STDOUT";
>             ]]>
>           </Script> 
>         <Route>
>           <OS390Appender name="OS390-${mdc:UserId"/> 
>           <RollingFile name="Rolling-${mdc:UserId}" fileName="${mdc:UserId}.log"
>                        filePattern="${mdc:UserId}.%i.log.gz">
>             <PatternLayout>
>               <pattern>%d %p %c{1.} [%t] %m%n</pattern>
>             </PatternLayout>
>             <SizeBasedTriggeringPolicy size="500" />
>           </RollingFile>
>         </Route>
>         <Route ref="AuditLogger" key="Audit"/>
>         <Route ref="STDOUT" key="STDOUT"/>
>       </Routes>
>       <IdlePurgePolicy timeToLive="15" timeUnit="minutes"/>
>     </Routing>
>   </Appenders>
> {code}
> First, the init script changes the default route based on the OS.
> Second, notice that "Routes" has a new Script element and does not have a pattern specified,
so the script is determining the key instead of the pattern. 
> Third, the real default route is now "STDOUT" since the actual default Route is only
referenced when a UserId is present in the thread context map.
> What would also be nice is if there was a way to have the returned value be usable as
a Lookup value in the default Appender definition, instead of relying on the MDC as the code
above does. I should be able to pick something out of the message itself and use that as the
key. That should be doable but I am still pondering how I would implement that.

This message was sent by Atlassian JIRA

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

View raw message