Ryan McKinley
added a comment - 17/Apr/12 19:22 I think it makes sense to have the logging page first show events, and only show the levels as a second step.
In SOLR-3358 , the logging events are returned as a SolrDocumentList so that we can have a unified UI if the events come from a search or the simple RAM buffer

About the Auto-Refresh Option .. I'm not really sure, would we like to have that? If so, will it be enough to have it enabled/disabled (like Autoload on Schema-Browser), or is there a need for additional settings like polling-interval and things like this?

Stefan Matheis (steffkes)
added a comment - 22/Apr/12 16:35 TBD:
Toggle-Option for trace information
Color-Coding for different Levels
Kind of 'Auto Refresh'
About the Auto-Refresh Option .. I'm not really sure, would we like to have that? If so, will it be enough to have it enabled/disabled (like Autoload on Schema-Browser), or is there a need for additional settings like polling-interval and things like this?

For ordering events – I like older events on the top and newer ones at the bottom. For Auto Refresh, just keep adding rows at the bottom. I don't think we need a "Load new Events" button – just put a spinner at the bottom and refresh every 5/10? seconds. similar to jenkins

rather then "~logging/config" maybe "~logging/level" since this does not really configure your logging

Ryan McKinley
added a comment - 23/Apr/12 01:54 Great start! A few comments:
color scale – I don't follow the color coding scheme. I would expect something where red is severe and blue is just info. something like: http://www.mediacollege.com/lighting/colour/colour-temperature.html
For ordering events – I like older events on the top and newer ones at the bottom. For Auto Refresh, just keep adding rows at the bottom. I don't think we need a "Load new Events" button – just put a spinner at the bottom and refresh every 5/10? seconds. similar to jenkins
rather then "~logging/config" maybe "~logging/level" since this does not really configure your logging
I like it

Stefan Matheis (steffkes)
added a comment - 23/Apr/12 18:37 So, how about this one?
The Handling of Auto-Scrolling right now is a bit poor, bit i'll have a look at the jenkins-one, that is really smooth.

Ryan McKinley
added a comment - 23/Apr/12 19:12 better – some things to consider
i don't think it is necessary to grey out the older events
rather then showing the long date form in Last Check, how about one that matches the format in the Time column
this patch is missing the 'logging.html' file
What do you think about adding something like:
Unable to find source-code formatter for language: css. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
#content #logging #viewer thead th.message
{
width:100%;
}
and giving the rest more padding – this way the layout will stay consistent when you open an exception.
To show exceptions... what about adding a whole row with <td colspan="4"> and letting you click anywhere on the row to show it? Perhaps a right-aligned column/icon to show that it has a trace?

Ryan McKinley
added a comment - 24/Apr/12 01:18 The auto-update continues to check even when you are not on the page!
Once I navigate away from logging page, I still see requests going to the logging handler!

To show exceptions... what about adding a whole row with <td colspan="4"> and letting you click anywhere on the row to show it?

I've included two Versions, one with the colspan and one without (you'll find these at lines 340-350). I like the one without colspan, because i find it easier to "follow" the list to the next row - but i'm also fine using the other one. just let me know which one we'd like to have :>

Stefan Matheis (steffkes)
added a comment - 26/Apr/12 08:24 To show exceptions... what about adding a whole row with <td colspan="4"> and letting you click anywhere on the row to show it?
I've included two Versions, one with the colspan and one without (you'll find these at lines 340-350). I like the one without colspan, because i find it easier to "follow" the list to the next row - but i'm also fine using the other one. just let me know which one we'd like to have :>

looks good stefan – i commited this in r1335204, but think we can continue making it better.

The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide – this is why i like the colspan version better. Looking at it more, I think it would be even better if we could use the 2nd level tab space (Viewer vs Level) as well.

What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible.

Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core?

Ryan McKinley
added a comment - 07/May/12 20:19 looks good stefan – i commited this in r1335204, but think we can continue making it better.
The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide – this is why i like the colspan version better. Looking at it more, I think it would be even better if we could use the 2nd level tab space (Viewer vs Level) as well.
What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible.
Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core?

I added the missing Icon in r1335229 - it's mentioned in the patch, but because it's a binary file, it's not fully included .

The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide

Hm, i played a bit around, but i didn't get such a huge stacktrace? Would you mind attaching one (as plain text), that i can check this one?

What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible.

Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core?

Hm, never thought about that ;o i just continued the Navigation-Logic which we used for f.e the Plugins. Will open a separate Ticket for that and start moving the Sub-Navigation for all "global" Items out to the left Panel - good idea!

Stefan Matheis (steffkes)
added a comment - 07/May/12 23:48 I added the missing Icon in r1335229 - it's mentioned in the patch, but because it's a binary file, it's not fully included .
The biggest thing I notice when using this with my real data/errors is that most severe errors are really big/wide
Hm, i played a bit around, but i didn't get such a huge stacktrace? Would you mind attaching one (as plain text), that i can check this one?
What do you think about putting "Level" as a sub-menu under "Logging" in the far left panel? This would give the viewer as much width as possible.
Can the 'Level' menu only show up when Logging is selected? similar to the options that show up when you select a core?
Hm, never thought about that ;o i just continued the Navigation-Logic which we used for f.e the Plugins. Will open a separate Ticket for that and start moving the Sub-Navigation for all "global" Items out to the left Panel - good idea!

Ryan McKinley
added a comment - 08/May/12 00:15 dooh – attached the screenshot to the wrong issue. This is what I see for errors on a small (ish) screen:
Do you need stacktrace for this? just putting in ?test=true should get you one too

Stefan Matheis (steffkes)
added a comment - 16/May/12 14:44 Hm, i think we should open another Issue for this, or do you think otherwise?
Because, if you check the difference between:
{
time: "2012-05-16T13:25:03.679Z" ,
level: "SEVERE" ,
logger: "org.apache.solr.handler.admin.LoggingHandler" ,
message: "error (with exception)" ,
trace: "java.lang.RuntimeException: test
at org.apache.solr.handler.admin.LoggingHandler.handleRequestBody(LoggingHandler.java:75)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
..."
}
(from /solr/admin/logging?wt=json&since=0&test=true )
and
{
time: "2012-05-16T13:26:10.722Z" ,
level: "SEVERE" ,
logger: "org.apache.solr.core.SolrCore" ,
message: "org.apache.solr.common.SolrException: Can not find: schema.not [/opt/solr-trunk/solr/example/solr/./conf/schema.not]
at org.apache.solr.handler.admin.ShowFileRequestHandler.showFromFileSystem(ShowFileRequestHandler.java:229)
at org.apache.solr.handler.admin.ShowFileRequestHandler.handleRequestBody(ShowFileRequestHandler.java:122)
..."
}
(from /solr/collection1/admin/file?file=schema.not&contentType=text/xml;charset=utf-8 )
it is pretty clear why your screen looks like what it looks *g it's just one big fat text-message, even the latest revision will not be able to display that in a good fashion.
the difference seems to be: throwing a new exception (directly) vs. calling a log.xy(), passing a exception as parameter, but can we (and should we?) change this behaviour?

ya, i see the difference. Obviously it is best if we can change the messages so they are reasonably short, but this is not realistic for all error messages. (yes, we should open an issue for this specific error, but it is not an easy fix)

Whatever format we pick should be able to support short or long messages (i think)

Ryan McKinley
added a comment - 18/Jun/12 22:23 ya, i see the difference. Obviously it is best if we can change the messages so they are reasonably short, but this is not realistic for all error messages. (yes, we should open an issue for this specific error, but it is not an easy fix)
Whatever format we pick should be able to support short or long messages (i think)
Perhaps overflow:hidden? or an option to toggle overflow:hidden?

Ah, perhaps i was not clear .. or just misunderstood your last comment?

The Length of the Message (itself) is not really a problem .. we could either use overflow:hidden, like you're already suggesting .. or break on whitespaces - that will both work.

My Point is about the Fact that second one contains the complete stacktrace as message-key. If we can split them, so that we have a message and a trace (like the first one) for every entry - that would be great .. but don't know if that would be possible?

Stefan Matheis (steffkes)
added a comment - 19/Jun/12 19:43 Ah, perhaps i was not clear .. or just misunderstood your last comment?
The Length of the Message (itself) is not really a problem .. we could either use overflow:hidden, like you're already suggesting .. or break on whitespaces - that will both work.
My Point is about the Fact that second one contains the complete stacktrace as message -key. If we can split them, so that we have a message and a trace (like the first one) for every entry - that would be great .. but don't know if that would be possible?

Ryan McKinley
added a comment - 19/Jun/12 21:18 the issue is that some exceptions take the output of 'cause' exceptions and put it in the message body
throw new RuntimeException( "error " +cause );
vs
throw new RuntimeException( "error message" , cause );
The UI should look OK regardless of how people create the error message, but yes keeping the cause as a trace element is much nicer. This is just an easy way to make a very long message string.

If the Record contains a trace-Index, everything is great - otherwise we take the message (which in this case will contain the whole thing) and split on the first newline .. using the former part as new message and the latter as trace.

I have to check if this works for only a few / most / or perhaps all exceptions i can get ;>

Stefan Matheis (steffkes)
added a comment - 20/Jun/12 19:50 Ah okay, makes sense. So, what about the following:
If the Record contains a trace -Index, everything is great - otherwise we take the message (which in this case will contain the whole thing) and split on the first newline .. using the former part as new message and the latter as trace .
I have to check if this works for only a few / most / or perhaps all exceptions i can get ;>
Will create a new Ticket for this.

Antony Stubbs
added a comment - 18/Jul/12 18:05 This functionality appears to break when using LogBack instead of the default setup.. Is there a known way to make it work with logback? Looks like a cool feature.