Right, by "current" I meant to read the logging setup and if there's
just one file appender, take it as default. Or, if that would be
inappropriate mixing of abstraction layers, just "server.log".
On 25.9.2013 12:06, Kabir Khan wrote:
Current log could be the server.log in a standard setup. If someone
has done something more advanced in their logging setup, the name becomes necessary
On 25 Sep 2013, at 08:34, Jaikiran Pai wrote:
> On Wednesday 25 September 2013 09:25 AM, Ondrej Zizka wrote:
>> 1) Could it have a "read-log-file()" without name= specified, which
would read the "current" log file?
> 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 file appenders) with different attributes and each such appender
writing out to a different file. So having a name of the log file you want to view,
>> 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?
>> On 25.9.2013 02:40, James R. Perkins wrote:
>>> I'm replying to this old thread to reopen this conversation about reading
log files. I've complete some work  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.
>>> What I've done is added two new operations list-log-files and
>>> 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
>>> 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;
>>> • name (required): the name of the log file to read
>>> • encoding: the encoding for the log file
>>> • lines: the number of lines to read, defaults to 10
>>> • skip: the number of lines to skip before adding the results
>>> • tail: true to read from the bottom up, default is true
>>> 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.
>>> So this begs the question, will this work for what we want? What concerns
does anyone else have?
>>> I have not yet submitted a PR yet as I wanted to get some feedback before we
bake it in.
>>> : https://github.com/jamezp/wildfly/compare/WFLY-280-read
>>> On 08/14/2013 10:03 AM, James R. Perkins wrote:
>>>> 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.
>>>> The original JIRA, WFLY-280, 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.
>>>> 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.
>>>> 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.
>>>> 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.
>>>> 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.
>>>> 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.
>>>> : https://issues.jboss.org/browse/WFLY-280
>>>> James R. Perkins
>>>> Red Hat JBoss Middleware
>>> James R. Perkins
>>> Red Hat JBoss Middleware
>>> wildfly-dev mailing list
>> wildfly-dev mailing list
> wildfly-dev mailing list