[jboss-jira] [JBoss JIRA] (LOGTOOL-84) Provide mechanism for preparing string representations of logged objects

[James Perkins (JIRA)]

     [ https://issues.jboss.org/browse/LOGTOOL-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed LOGTOOL-84.
--------------------------------
    Resolution: Out of Date


Cleaning up old JIRA's and this sounds like there is a solution for it.

> Provide mechanism for preparing string representations of logged objects
> ------------------------------------------------------------------------
>
>                 Key: LOGTOOL-84
>                 URL: https://issues.jboss.org/browse/LOGTOOL-84
>             Project: Log Tool
>          Issue Type: Feature Request
>            Reporter: Gunnar Morling
>            Assignee: David Lloyd
>
> There are cases where a fine-grained control of the string representation of logged objects in log messages would be useful.
> When logging {{Class}} objects for instance, we would like to see the fully-qualified name of the given class in the log message. Currently we get _(class|interface) com.acme.Foo_, though, as per the implementation of {{j.l.Class#toString()}}, which prepends the type of the given class object.
> As workaround, we currently define the log method to accept a String parameter and pass {{myClass.getName()}} to it. Having a strongly typed log method which takes the "real" object as parameter seems preferable, though.
> A possible solution could be a mechanism which allows to register to-string converters for given types with a logger:
> {code}
> //Provided by JBoss Logging API
> public interface StringConverter<T> {
>     String createString(T object);
> }
> //A project-specific implementation
> public class ClassStringConverter implements StringConverter<Class<?>> {
>     public String createString(Class<?> object) {
>         return object.getName();
>     }
> }
> //Project-specific logger, references 1..n converters
> @MessageLogger(projectCode = "HV", converters=ClassStringConverter.class)
> public interface Log extends BasicLogger {
>     //implementation uses converter to create string representation of given class
>     @LogMessage(level = INFO)
>     @Message(id = 1, value = "Illegal class %s")
>     void illegalClass(Class<?> clazz);
> }
> {code}
> Would such a feature make sense to you?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)