4:58 p.m.
On 7/1/13 4:36 PM, James R. Perkins wrote:
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.
I don't see much benefit in B vs having 2 attributes,
"pattern-formatter" and "custom-formatter", with the current
"formatter"
just an alias for "pattern-formatter.format-pattern".
With a single "formatter" in B the attribute description is going to
have to describe how in the complex attribute there are two possible
keys "pattern" and "custom", only one of which is valid at a time. A
client is then going to have to figure out which of the two a given
response includes and parse accordingly.
Your option B really looks more like you have a child resource type
"formatter" instead of an attribute, with two legal values for the
resource name -- "pattern" and "custom".
A model change
like this would also require some transformers for backwards
compatibility. Though that doesn't really bother me all that much.
It also breaks any existing clients who are expecting the "formatter"
attribute to be ModelType.STRING.
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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat