<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I'm replying to this old thread to reopen this conversation about
    reading log files. I've complete some work [1] on reading log files
    via an operation. This is not exactly like the JIRA suggests where
    it would only read the last 10 error messages. All this change
    allows is the raw contents of the file to be read. The idea is this
    could be used to read the entire contents of the log file as a
    whole, or in chunks.<br>
    <br>
    What I've done is added two new operations list-log-files and
    read-log-file.<br>
    <br>
    The list-log-files simply lists all files in the
    jboss.server.log.dir. This may or may not be a good idea really. I
    can see some potential security risks here mainly just seeing files
    that may contain sensitive data. One way I've thought of to get
    around that is read the logging subsystem model and only show files
    from known types like the file-handlers. The main issue with that is
    there is no good way to get this to work for custom-handlers.<br>
    <br>
    The read-log-file simple does what it says and reads the contents of
    a log file line by line. Reading line by line should work for the
    most part unless the an non-standard line delimiter is used. There
    are 5 options for this option;<br>
    <ul>
      <li>name (required): the name of the log file to read</li>
      <li>encoding: the encoding for the log file</li>
      <li>lines: the number of lines to read, defaults to 10</li>
      <li>skip: the number of lines to skip before adding the results</li>
      <li>tail: true to read from the bottom up, default is true</li>
    </ul>
    <p>The result of this is just a list of lines with the \n or \r\n
      stripped. Just to clarify too a line means a line in the file, not
      a log record e.g. stack traces are generally composed of multiple
      lines.<br>
    </p>
    <p>So this begs the question, will this work for what we want? What
      concerns does anyone else have?<br>
    </p>
    <p>I have not yet submitted a PR yet as I wanted to get some
      feedback before we bake it in.<br>
    </p>
    <br>
    [1]:
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="https://github.com/jamezp/wildfly/compare/WFLY-280-read">https://github.com/jamezp/wildfly/compare/WFLY-280-read</a><br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 08/14/2013 10:03 AM, James R.
      Perkins wrote:<br>
    </div>
    <blockquote cite="mid:520BB865.6000102@redhat.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      I had posted this to another list, but this is a more appropriate
      place for it. I think there needs to be a general discussion
      around this as it's been mentioned, at least to me, a few times
      here and there and I know Heiko raised the issue some time a go
      now.<br>
      <br>
      The original JIRA, WFLY-280[1], is to display the last 10 error
      messages only. To be honest I wouldn't find that very useful. To
      me if I'm looking for logs I want to see all logs, but that's not
      always so easy. Like the syslog-handler which doesn't log to a
      file so there is no way to read those messages back. <br>
      <br>
      The current plan for the last 10 error messages is we store
      messages in a queue that can be accessed via an operation. This
      works fine until the error message you're interested in is 11 or
      you want to see warning messages. <br>
      <br>
      Another option I had come up with is reading back the contents of
      the file, for example the server.log. This could be problematic
      too in that there is no way to filter information like only see
      error messages or only see warning messages. To solve this I have
      considered creating a JSON formatter so the results could be
      queried, but I don't think it should be a default which would mean
      it's not reliable for the console to assume it's getting back
      JSON. <br>
      <br>
      I've also thought about, haven't tested this and it may not work
      at all, creating a handler that uses websockets to send messages.
      I'm not sure how well this would work and it's possible it may not
      even work for bootstrap logging. <br>
      <br>
      With regards to audit logging, we're probably going to have to do
      something totally different from what we'll do in the logging
      subsystem since it doesn't use standard logging. <br>
      <br>
      I guess the bottom line is what does the console want to see? Do
      you want to see all raw text log messages? Do you want all
      messages but in a format like JSON that you can query/filter? Do
      you really want only the last 10 error messages only? All or none
      of these might be possible, but I really need to understand the
      needs before I can explore more in depth what the best option
      would be.<br>
      <br>
      [1]:
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <a moz-do-not-send="true"
        href="https://issues.jboss.org/browse/WFLY-280">https://issues.jboss.org/browse/WFLY-280</a>
      <pre class="moz-signature" cols="72">-- 
James R. Perkins
Red Hat JBoss Middleware</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
James R. Perkins
Red Hat JBoss Middleware</pre>
  </body>
</html>