<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><tt>On Wednesday 25 September 2013
        09:25 AM, Ondrej Zizka wrote:</tt><tt><br>
      </tt></div>
    <blockquote cite="mid:52425EA7.4060502@redhat.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <tt> 1) Could it have a "read-log-file()" without name= specified,
        which would read the "current" log file?</tt><tt><br>
      </tt></blockquote>
    <tt>Given the way logger categories and appenders/handlers interact,
      within a logging framework, I don't think there's any notion of
      "current log file". It's a very valid scenario where a single
      logging category can be backed by different appenders (some of
      them</tt><tt> file appenders) with different attributes and each
      such appender writing out to a different file.</tt><tt> So having
      a name of the log file you want to view, becomes necessary.<br>
    </tt><tt><br>
    </tt><tt>-Jaikiran</tt><tt><br>
    </tt><tt><br>
    </tt>
    <blockquote cite="mid:52425EA7.4060502@redhat.com" type="cite"><tt>
        2) Regarding security - what, besides logs, do we expect to be
        in the log dir? Could the admin block it by setting write-only
        rights?</tt><tt><br>
      </tt> <tt><br>
      </tt><tt> Ondra</tt><tt><br>
      </tt> <tt><br>
      </tt>
      <div class="moz-cite-prefix"><tt>On 25.9.2013 02:40, James R.
          Perkins wrote:</tt><tt><br>
        </tt> </div>
      <blockquote cite="mid:52423105.6080106@redhat.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <tt> 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.</tt><tt><br>
        </tt> <tt><br>
        </tt><tt> What I've done is added two new operations
          list-log-files and read-log-file.</tt><tt><br>
        </tt> <tt><br>
        </tt><tt> 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.</tt><tt><br>
        </tt> <tt><br>
        </tt><tt> 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;</tt><tt><br>
        </tt>
        <ul>
          <li><tt>name (required): the name of the log file to read</tt></li>
          <li><tt>encoding: the encoding for the log file</tt></li>
          <li><tt>lines: the number of lines to read, defaults to 10</tt></li>
          <li><tt>skip: the number of lines to skip before adding the
              results</tt></li>
          <li><tt>tail: true to read from the bottom up, default is true</tt></li>
        </ul>
        <p><tt>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.</tt><tt><br>
          </tt> </p>
        <p><tt>So this begs the question, will this work for what we
            want? What concerns does anyone else have?</tt><tt><br>
          </tt> </p>
        <p><tt>I have not yet submitted a PR yet as I wanted to get some
            feedback before we bake it in.</tt><tt><br>
          </tt> </p>
        <tt><br>
        </tt><tt> [1]: </tt>
        <meta http-equiv="content-type" content="text/html;
          charset=ISO-8859-1">
        <tt> </tt><tt><a moz-do-not-send="true"
            href="https://github.com/jamezp/wildfly/compare/WFLY-280-read">https://github.com/jamezp/wildfly/compare/WFLY-280-read</a></tt><tt><br>
        </tt> <tt><br>
        </tt> <tt><br>
        </tt>
        <div class="moz-cite-prefix"><tt>On 08/14/2013 10:03 AM, James
            R. Perkins wrote:</tt><tt><br>
          </tt> </div>
        <blockquote cite="mid:520BB865.6000102@redhat.com" type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          <tt> 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.</tt><tt><br>
          </tt> <tt><br>
          </tt><tt> 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. </tt><tt><br>
          </tt> <tt><br>
          </tt><tt> 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. </tt><tt><br>
          </tt> <tt><br>
          </tt><tt> 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. </tt><tt><br>
          </tt> <tt><br>
          </tt><tt> 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. </tt><tt><br>
          </tt> <tt><br>
          </tt><tt> 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. </tt><tt><br>
          </tt> <tt><br>
          </tt><tt> 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.</tt><tt><br>
          </tt> <tt><br>
          </tt><tt> [1]: </tt>
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          <tt> </tt><tt><a moz-do-not-send="true"
              href="https://issues.jboss.org/browse/WFLY-280">https://issues.jboss.org/browse/WFLY-280</a></tt>
          <pre class="moz-signature" cols="72">-- 
James R. Perkins
Red Hat JBoss Middleware</pre>
        </blockquote>
        <tt><br>
        </tt>
        <pre class="moz-signature" cols="72">-- 
James R. Perkins
Red Hat JBoss Middleware</pre>
        <tt><br>
        </tt>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <tt><br>
        </tt>
        <pre wrap="">_______________________________________________
wildfly-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
      </blockquote>
      <tt><br>
      </tt> <tt><br>
      </tt>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <tt><br>
      </tt>
      <pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
    </blockquote>
    <tt><br>
    </tt>
  </body>
</html>