[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    Re: "host" and "application" event properties in LogFileXMLReceiver
From:       Scott Deboy <scott.deboy () gmail ! com>
Date:       2012-10-26 16:42:46
Message-ID: CADBq88DjPYG_Bf9zp8VfpHAr3RA43kG+fghc1pkJirgYdx6Q5Q () mail ! gmail ! com
[Download RAW message or body]

Hi Jim,

Thanks for the patch - it looks good - I'll apply it.

Scott

On Fri, Oct 26, 2012 at 6:10 AM, Mayer, Jim <Jim.Mayer@xerox.com> wrote:

> Hi,
>
> I've been using a recent trunk version of chainsaw to look at log files
> created with log4j's org.apache.log4j.xml.XMLLayout layout.  I noticed that
> when I configure a LogFileXMLReceiver to open a log file from a well-known
> location that the imported events do not contain a 'hostname' or
> 'application' property.  This, of course, plays havoc with event routing.
>
> A bit of investigation showed that when a log file is opened that the
> FileLoadAction class uses the 'setAdditionalProperties' method on the
> decoder to add the file and path as the host and application properties.
>  This doesn't happen when configuring a LogFileXMLReceiver directly.  When
> I looked at the LogFileXMLReceiver code I saw that it contains the
> following logic (for each event):
>
>                 if (evt.getProperty(Constants.HOSTNAME_KEY) != null) {
>                     evt.setProperty(Constants.HOSTNAME_KEY, host);
>                 }
>                 if (evt.getProperty(Constants.APPLICATION_KEY) != null) {
>                     evt.setProperty(Constants.APPLICATION_KEY, path);
>                 }
>
> This has the effect of setting the hostname and application properties of
> the event to the string "file" and the file path of the configured source
> URL, but only if the event being processed contained "hostname" and
> "application" properties.  This behavior seems somewhat strange... if I've
> gone to the trouble of setting the 'hostname' and 'application' properties
> in the log, I'd expect them to be used.
>
> The following patch changes this behavior as follows:
>
> (1) The event will always have a 'hostname' and 'application' property.
> (2) The default value of the hostname property is 'file'.
> (3) The default value of the application property is the path to the log
> file.
> (4) If an event includes a 'hostname' or 'application' property it will
> override the corresponding default value.
>
> The end result of this change is that files configured with
> LogFileXMLReceiver act, by default, as if they were opened directly (i.e.,
> they use the 'file' URL information for routing).  If the generating
> application adds 'application' or 'hostname' properties to the logged
> events, however, those properties will be used for routing.
>
> I hope you find this useful.
>
> -- Jim Mayer
>
> -------------------- START OF DIFF ------------------
> Index: src/main/java/org/apache/log4j/xml/LogFileXMLReceiver.java
> ===================================================================
> --- src/main/java/org/apache/log4j/xml/LogFileXMLReceiver.java  (revision
> 1397548)
> +++ src/main/java/org/apache/log4j/xml/LogFileXMLReceiver.java  (working
> copy)
> @@ -276,12 +276,17 @@
>          for (Iterator iter = c.iterator(); iter.hasNext();) {
>              LoggingEvent evt = (LoggingEvent) iter.next();
>              if (passesExpression(evt)) {
> -                if (evt.getProperty(Constants.HOSTNAME_KEY) != null) {
> -                    evt.setProperty(Constants.HOSTNAME_KEY, host);
> +               String theHost = host;
> +               String theApp = path;
> +               String v;
> +                if ((v = evt.getProperty(Constants.HOSTNAME_KEY)) !=
> null) {
> +                   theHost = v;
>                  }
> -                if (evt.getProperty(Constants.APPLICATION_KEY) != null) {
> -                    evt.setProperty(Constants.APPLICATION_KEY, path);
> +                if ((v = evt.getProperty(Constants.APPLICATION_KEY)) !=
> null) {
> +                   theApp = v;
>                  }
> +               evt.setProperty(Constants.HOSTNAME_KEY, theHost);
> +               evt.setProperty(Constants.APPLICATION_KEY, theApp);
>                  doPost(evt);
>              }
>          }
> @@ -307,4 +312,4 @@
>          this.useCurrentThread = useCurrentThread;
>      }
>
> -}
> \ No newline at end of file
> +}
> ------------------- END OF DIFF ----------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>

[Attachment #3 (text/html)]

Hi Jim,<br><br>Thanks for the patch - it looks good - I&#39;ll apply \
it.<br><br>Scott<br><br><div class="gmail_quote">On Fri, Oct 26, 2012 at 6:10 AM, \
Mayer, Jim <span dir="ltr">&lt;<a href="mailto:Jim.Mayer@xerox.com" \
target="_blank">Jim.Mayer@xerox.com</a>&gt;</span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi,<br> <br>
I&#39;ve been using a recent trunk version of chainsaw to look at log files created \
with log4j&#39;s org.apache.log4j.xml.XMLLayout layout.  I noticed that when I \
configure a LogFileXMLReceiver to open a log file from a well-known location that the \
imported events do not contain a &#39;hostname&#39; or &#39;application&#39; \
property.  This, of course, plays havoc with event routing.<br>

<br>
A bit of investigation showed that when a log file is opened that the FileLoadAction \
class uses the &#39;setAdditionalProperties&#39; method on the decoder to add the \
file and path as the host and application properties.  This doesn&#39;t happen when \
configuring a LogFileXMLReceiver directly.  When I looked at the LogFileXMLReceiver \
code I saw that it contains the following logic (for each event):<br>

<br>
                if (evt.getProperty(Constants.HOSTNAME_KEY) != null) {<br>
                    evt.setProperty(Constants.HOSTNAME_KEY, host);<br>
                }<br>
                if (evt.getProperty(Constants.APPLICATION_KEY) != null) {<br>
                    evt.setProperty(Constants.APPLICATION_KEY, path);<br>
                }<br>
<br>
This has the effect of setting the hostname and application properties of the event \
to the string &quot;file&quot; and the file path of the configured source URL, but \
only if the event being processed contained &quot;hostname&quot; and \
&quot;application&quot; properties.  This behavior seems somewhat strange... if \
I&#39;ve gone to the trouble of setting the &#39;hostname&#39; and \
&#39;application&#39; properties in the log, I&#39;d expect them to be used.<br>

<br>
The following patch changes this behavior as follows:<br>
<br>
(1) The event will always have a &#39;hostname&#39; and &#39;application&#39; \
property.<br> (2) The default value of the hostname property is &#39;file&#39;.<br>
(3) The default value of the application property is the path to the log file.<br>
(4) If an event includes a &#39;hostname&#39; or &#39;application&#39; property it \
will override the corresponding default value.<br> <br>
The end result of this change is that files configured with LogFileXMLReceiver act, \
by default, as if they were opened directly (i.e., they use the &#39;file&#39; URL \
information for routing).  If the generating application adds &#39;application&#39; \
or &#39;hostname&#39; properties to the logged events, however, those properties will \
be used for routing.<br>

<br>
I hope you find this useful.<br>
<br>
-- Jim Mayer<br>
<br>
-------------------- START OF DIFF ------------------<br>
Index: src/main/java/org/apache/log4j/xml/LogFileXMLReceiver.java<br>
===================================================================<br>
--- src/main/java/org/apache/log4j/xml/LogFileXMLReceiver.java  (revision \
                1397548)<br>
+++ src/main/java/org/apache/log4j/xml/LogFileXMLReceiver.java  (working copy)<br>
@@ -276,12 +276,17 @@<br>
         for (Iterator iter = c.iterator(); iter.hasNext();) {<br>
             LoggingEvent evt = (LoggingEvent) iter.next();<br>
             if (passesExpression(evt)) {<br>
-                if (evt.getProperty(Constants.HOSTNAME_KEY) != null) {<br>
-                    evt.setProperty(Constants.HOSTNAME_KEY, host);<br>
+               String theHost = host;<br>
+               String theApp = path;<br>
+               String v;<br>
+                if ((v = evt.getProperty(Constants.HOSTNAME_KEY)) != null) {<br>
+                   theHost = v;<br>
                 }<br>
-                if (evt.getProperty(Constants.APPLICATION_KEY) != null) {<br>
-                    evt.setProperty(Constants.APPLICATION_KEY, path);<br>
+                if ((v = evt.getProperty(Constants.APPLICATION_KEY)) != null) {<br>
+                   theApp = v;<br>
                 }<br>
+               evt.setProperty(Constants.HOSTNAME_KEY, theHost);<br>
+               evt.setProperty(Constants.APPLICATION_KEY, theApp);<br>
                 doPost(evt);<br>
             }<br>
         }<br>
@@ -307,4 +312,4 @@<br>
         this.useCurrentThread = useCurrentThread;<br>
     }<br>
<br>
-}<br>
\ No newline at end of file<br>
+}<br>
------------------- END OF DIFF ----------------------<br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a \
href="mailto:log4j-dev-unsubscribe@logging.apache.org">log4j-dev-unsubscribe@logging.apache.org</a><br>
 For additional commands, e-mail: <a \
href="mailto:log4j-dev-help@logging.apache.org">log4j-dev-help@logging.apache.org</a><br>
 <br>
</blockquote></div><br>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic