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

[Gunnar Morling (JIRA)]

    [ https://issues.jboss.org/browse/LOGTOOL-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020480#comment-13020480 ] 

Gunnar Morling commented on LOGTOOL-84:
---------------------------------------

Yes, it seems related. In fact, {{@FormatWith}} appears to be what I'm after, just learned about it. I'll give that a try. Though what I had in mind here would go a bit farther, as it basically would specify default {{@FormatWith}} 's based on the parameter type, without the need to specify the formatter type for each single parameter. 

Btw. the pull request for LOGTOOL-55 is merged, still the issue itself is open. Shouldn't it be marked as resolved?

> 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
(v6.3.8#6338)