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