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