[wildfly-dev] Logging Model Changes and Questions

[James R. Perkins]

I talked to Tomaz a bit about this last Friday, but thought I would open 
it up to a wider audience and get others opinions as well.

All handlers, except the async-handler, have an attribute called 
formatter. The formatter allows a string value which is the pattern used 
to format the log message. This only allows for the use of the 
org.jboss.logmanager.formatters.PatternFormatter.

There is a JIRA [1], I thought an RFE too but I can't find it, to allow 
for the use of custom formatters. For example the use of 
java.util.logging.XMLFormatter. I actually think this could be useful. 
Possibly something like a JSONFormatter to help the console team with 
displaying log messages on the web console [2].

There is also a JIRA [3] to allow the colors for the log output to be 
changed.

The current model, we'll just use the console-handler for simplicity, 
looks like the following:
{
     "outcome" => "success",
     "result" => {
         "autoflush" => true,
         "enabled" => true,
         "encoding" => undefined,
         "filter" => undefined,
         "filter-spec" => undefined,
         "formatter" => "%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
         "level" => "INFO",
         "name" => "CONSOLE",
         "target" => "System.out"
     }
}

The easiest option (A) in both cases would be to add something like a 
"custom-formatter" attribute and a "formatter-color-mapping" attribute. 
What bothers me about this though is it doesn't seem logical. Having 
attributes that may or may not be used together doesn't make a lot of 
sense to me.

Another option (B) would be to change the model to look something like:
{
     "outcome" => "success",
     "result" => {
         "autoflush" => true,
         "enabled" => true,
         "encoding" => undefined,
         "filter" => undefined,
         "filter-spec" => undefined,
         "formatter" => {
             "pattern" => {
                 "format-pattern" => "%K{level}%d{HH:mm:ss,SSS} %-5p 
[%c] (%t) %s%E%n",
                 "color-mapping" => "warn=yellow,error=red,info=clear"
             }
         },
         "level" => "INFO",
         "name" => "CONSOLE",
         "target" => "System.out"
     }
}

-- OR --

{
     "outcome" => "success",
     "result" => {
         "autoflush" => true,
         "enabled" => true,
         "encoding" => undefined,
         "filter" => undefined,
         "filter-spec" => undefined,
         "formatter" => {
             "custom" => {
                 "module" => "sun.jdk",
                 "class" => "java.util.logging.XMLFormatter",
                 "properties" => {
                     "key1" => "value1",
                     "key2" => "value2"
                 }
             }
         },
         "level" => "INFO",
         "name" => "CONSOLE",
         "target" => "System.out"
     }
}

I know some people don't like complex attribute values. Personally I 
don't mind them, but they are a PITA with regards to CLI. A model change 
like this would also require some transformers for backwards 
compatibility. Though that doesn't really bother me all that much.

Anyone have opinions on should be used? I tend to lean option B because 
it feels more logical.

[1]: https://issues.jboss.org/browse/WFLY-1188
[2]: https://issues.jboss.org/browse/WFLY-1144
[3]: https://issues.jboss.org/browse/WFLY-1059

-- 
James R. Perkins
Red Hat JBoss Middleware

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130701/5a014342/attachment.html