[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2213: --------------------------------------- A quick thought on how to do this -- add a new appender that stores a configurable number of messages in memory. I don't want to go hacking into the logging subsystem to try and figure out which appender is the server.log appender and then go find the file and grep it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-2213: ---------------------------------- Assignee: (was: Brian Stansberry) Fix Version/s: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Heiko Braun commented on AS7-2213: ---------------------------------- i think "since current time" will do. something like {noformat} getLogMessages(String logLevel, int maxMessages); {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Heiko Braun commented on AS7-2213: ---------------------------------- it's quiet the opposite, no? I think it cannot get any more simple then "give the last 15 messages within the ERROR level". But maybe I don't understand your point. Ping me on IRC for further discussions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Heiko Braun commented on AS7-2213: ---------------------------------- anytime between 8-16 GMT+1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Heiko Braun reassigned AS7-2213: -------------------------------- Assignee: Brian Stansberry -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Heiko Braun reassigned AS7-2213: -------------------------------- Assignee: Brian Stansberry (was: James Perkins) re-assign to brian to review the schedule. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned AS7-2213: ------------------------------------- Assignee: James Perkins (was: Brian Stansberry) If James can do it for 7.2.0.CR1, that would be great. But I don't control his schedule, and I don't have resources under my control that I can assign to this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2213: --------------------------------------- If we want this to be able to store and retrieve arbitrary amounts of data, then the custom appender that stores data could store it in the data/ dir in a custom format, allowing as much data as is desired and queries for as long as is desired. You get into all the issues of log file management though; the need to rollover and the need to clean out old logs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2213: --------------------------------------- You're right. We -- well, really you ;) -- need to understand the requirements of this and AS7-1311 better. There are two basic concerns I have here: 1) What is "the log"? There can be as many "logs" as there are appenders people have created in the system, including application specific ones. The output of some of them may not even be accessible to the services we use to satisfy this JIRA and AS7-1311. And there's nothing magical about server.log -- it's just the output of an appender we happen to provide in our standard logging subsystem configurations. It may not exist, it may be called foo.log, etc. So any solution to this will need to provide an intuitive way for the user to tell us what the logging of interest is. 2) How to parse "the log"? Maybe this is no big deal. I'm sure it's not unsolvable since there are plenty of log analysis tools out there. But if we support reporting back the contents of any particular log file, we need to be able to parse those contents. To recognize what sequence of text represents a new log entry vs a new line in an existing entry. And for this JIRA we also need to understand where in the log record the severity information is encoded. My naive thinking for this issue was to cut through these two problems by having a custom appender to track relevant output. But, such an approach doesn't help with the AS7-1311 problem and has other flaws, so it's best to figure out solutions for both this and AS7-1311. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] James Perkins commented on AS7-2213: ------------------------------------ My first thought is it feels kind of fragile. If a user changes the the logging levels for any of the categories you're looking for you might not see anything. It also seems guessing the number of errors to go back may or may not work. Another thing to consider is we can't rely on the log manager is JBoss Log Manager. I've done some work on AS7-5785 to allow for other log managers to be used. In order for this to work the logging extension would have to be enabled. Note I'm not opposed to this at all, just want to put all the possible issues out there. Is it worth maybe listing all the log files in the {{jboss.server.log.dir}} and allow the user to view the files? Probably limiting the view to the last x lines, but make it configurable. With an approach like that you could add a link to the message to view the logs. Just kind of thinking out loud here though... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] James Perkins commented on AS7-2213: ------------------------------------ If that's the case then, should it just be a custom operation? That would be pretty simple. {code} /subsystem=logging:read-log-messages(category="org.jboss.as", min-level="WARN", max-messages=10) {code} The category could be stretching it a bit, but it could be useful too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] James Perkins commented on AS7-2213: ------------------------------------ With an operation my initial thought was just to add a file handler that outputs to the data directory like you originally. If done via the logging subsystem then manually adding a handler to the same file would work. Each log context that gets created for whatever reason could just add the same handler which would output all log messages to the file. It sounds like the first step then might be to write a log parser which I know Jesper has asked for separately anyway. I can start there while we work out the other details. As far as the host controller and the process controller, maybe we just add the handler there and in domain mode we just have a more global operation. Domain does require JBoss Log Manager, so adding a dependency there isn't a huge issue I don't think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2213: --------------------------------------- BTW, I'm not really arguing one way or another about the best approach here; I'm just trying to lay out all the issues I see. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2213?page=com.atlassian.jira.plugin.s... ] James Perkins commented on AS7-2213: ------------------------------------ One additional thought is we could return a list of complex DMR objects that represent a {{LogRecord}}. That would give the relevant information to the client then the client would be responsible for the output format. Just to show an example of the operation I was thinking of: {code} /subsystem=logging:read-log-messages {code} We could add parameters to narrow it down, but we'd still be limited to the number of messages in the queue. The same operation could be placed somewhere more globally that would access the PC and HC queue for domain mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira