[wildfly-dev] Logging Model Changes and Questions

[Brian Stansberry]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat