[
https://issues.apache.org/jira/browse/LOG4J2-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-166.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.0-beta9
The problem was that when the default route was selected it was not returning
the AppenderControl. This has been resolved in revision 1505102. Please verify
and close.
> Routing Appender default Route broken for references
> ----------------------------------------------------
>
> Key: LOG4J2-166
> URL: https://issues.apache.org/jira/browse/LOG4J2-166
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-beta4, 2.0-beta5, 2.0-beta6
> Reporter: David Johle
> Labels: appender, config, configuration, route, routing
> Fix For: 2.0-beta9
>
>
> I recently updated to using beta4 and ran into a problem upon startup where I
> received numerous errors such as this:
> 2013-02-14 12:27:40,139 ERROR No Appender was configured for route null
> Everything was working great up though beta3. After tracing it back, I think
> I found that it relates to the change Ralph alluded to in LOG4J2-129...
> "The problem was that the code was treating the Appender being created under
> the default Route as the default. That is incorrect. The code has been
> modified to just keep track of the default route."
> I think my setup was relying on that incorrect behavior, and that it's
> somewhat similar to what William is trying to accomplish.
> (His comment:
> https://issues.apache.org/jira/browse/LOG4J2-129?focusedCommentId=13553008&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13553008
> )
> I have several appenders created, and a routing appender to map events to
> them using static definitions. I also have a catch-all appender where I want
> all non-matched events to be sent. The [abbreviated] configuration is like
> this:
> {code}
> <appenders>
> <RollingFile name="apples" fileName="logs/apples"
> filePattern="logs/apples.%d{yyyy-MM-dd}">
> <PatternLayout pattern="${commonLayout}"/>
> <Policies>
> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
> </Policies>
> </RollingFile>
> <RollingFile name="oranges" fileName="logs/oranges"
> filePattern="logs/oranges.%d{yyyy-MM-dd}">
> <PatternLayout pattern="${commonLayout}"/>
> <Policies>
> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
> </Policies>
> </RollingFile>
> <RollingFile name="other" fileName="logs/other"
> filePattern="logs/other.%d{yyyy-MM-dd}">
> <PatternLayout pattern="${commonLayout}"/>
> <Policies>
> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
> </Policies>
> </RollingFile>
> <Routing name="Routing">
> <Routes pattern="$${ctx:fruit}">
> <Route key="apples" ref="apples"/>
> <Route key="oranges" ref="oranges"/>
> <Route ref="other"/>
> </Routes>
> </Routing>
> </appenders>
> {code}
> So the idea is that anything which has a ctx:fruit value of apples/oranges
> goes into the specific files, any everything else (regardless of ctx:fruit
> being defined or not) going into the "other" file.
> At startup time, most (if not all) events fall into the case of not having
> ctx:fruit defined at all. And during my debugging, I saw that "...the
> replacement won't occur if the context value isn't present.." as William
> mentioned.
> In RoutingAppender.java on line 107 there is:
> final String key = config.getSubst().replace(event, routes.getPattern());
> The value that ends up being assigned is the literal string "$\{ctx:fruit\}"
> instead of null. As a result, it chooses the default Route entry of "other"
> which hasn't been created yet, so it proceeds to create that appender. So
> far so good, until...
> In RoutingAppender.java on lines 142-144 there is:
> {code}
> final Node routeNode = route.getNode();
> for (final Node node : routeNode.getChildren()) {
> if (node.getType().getElementName().equals("appender")) {
> {code}
> I traced the execution and routeNode.getChildren() returns an empty list. I
> believe this is due to the <Route/> entries in the config...they don't have
> any child nodes because they are just referencing some existing appenders.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
