4:36 p.m.
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