On 8/14/13 12:55 PM, James R. Perkins wrote:
That's my thinking too. The only complaint I've had about
is that it can't be filtered since it's just raw text. I had a working
example operation that just took a file name and the number of bytes to
read. To me this is the best solution, but it wouldn't have access to
anything in a syslog or the console. Though that's okay IMO since they
likely have other viewers for those.
I'll resurrect that example. It shouldn't take all that long. One thing
to note is it will only allow files to be read that are in the
jboss.server.log.dir (and possibly only files that end in *.log?).
That's only true if the viewer operation is not associated with a
management resource that maps to the log file (i.e. the appender resource).
I think it's a mistake to create any kind of viewer that can serve an
For cases of serving previous versions of the file (i.e. ones before the
current with any kind of rolling appender) the API can expose a param
that allows the desired file to be chosen but only from a set of files
that the management resource knows it created.
So in general I agree here, I think this is the best, the least
approach and the lowest performance hit.
On 08/14/2013 10:36 AM, Jason Greene wrote:
> IMO the best solution is a management operation that simply displays portions of the
log file. The dependency on the log file is IMO not a problem because we support multiple
> On Aug 14, 2013, at 12:03 PM, James R. Perkins <jperkins(a)redhat.com> 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
>> 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
>> 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
>> wildfly-dev mailing list
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
Principal Software Engineer
JBoss by Red Hat