[JBoss JIRA] (LOGTOOL-84) Provide mechanism for preparing string representations of logged objects
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-84?page=com.atlassian.jira.plugin... ]
David Lloyd moved JBLOGGING-93 to LOGTOOL-84:
---------------------------------------------
Project: Log Tool (was: JBoss Logging)
Key: LOGTOOL-84 (was: JBLOGGING-93)
Affects Version/s: (was: 3.1.2.GA)
Component/s: (was: jboss-logging-spi)
> 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
> Security Level: Public(Everyone can see)
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (LOGTOOL-84) Provide mechanism for preparing string representations of logged objects
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-84?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGTOOL-84:
------------------------------------
Sounds similar to LOGTOOL-55?
> 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
> Security Level: Public(Everyone can see)
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (LOGMGR-98) Disable UTF-8 BOM in syslog handler when encoding is undefined
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-98?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on LOGMGR-98:
-----------------------------------
If the platform encoding is UTF-8, this will definitely cause confusion.
> Disable UTF-8 BOM in syslog handler when encoding is undefined
> --------------------------------------------------------------
>
> Key: LOGMGR-98
> URL: https://issues.jboss.org/browse/LOGMGR-98
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Kyle Lape
> Assignee: James Perkins
>
> Section 6.4 MSG: http://tools.ietf.org/html/rfc5424#section-6.4
> bq. If a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. The syslog application MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence.
> While we want to conform to the spec, it is desirable to not include the BOM in some practical applications, e.g. rsyslog does not strip the BOM, and sometimes it would be easier to be able to configure JBoss to not include the BOM than to configure rsyslog to drop it.
> Perhaps we can not include the BOM is the encoding is undefined for the {{SyslogHandler}}, but do include it if the {{encoding}} is explicitly set to {{UTF-8}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (LOGMGR-98) Disable UTF-8 BOM in syslog handler when encoding is undefined
by Kyle Lape (JIRA)
Kyle Lape created LOGMGR-98:
-------------------------------
Summary: Disable UTF-8 BOM in syslog handler when encoding is undefined
Key: LOGMGR-98
URL: https://issues.jboss.org/browse/LOGMGR-98
Project: JBoss Log Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Kyle Lape
Assignee: David Lloyd
Section 6.4 MSG: http://tools.ietf.org/html/rfc5424#section-6.4
bq. If a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. The syslog application MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence.
While we want to conform to the spec, it is desirable to not include the BOM in some practical applications, e.g. rsyslog does not strip the BOM, and sometimes it would be easier to be able to configure JBoss to not include the BOM than to configure rsyslog to drop it.
Perhaps we can not include the BOM is the encoding is undefined for the {{SyslogHandler}}, but do include it if the {{encoding}} is explicitly set to {{UTF-8}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (LOGMGR-98) Disable UTF-8 BOM in syslog handler when encoding is undefined
by Kyle Lape (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-98?page=com.atlassian.jira.plugin.... ]
Kyle Lape updated LOGMGR-98:
----------------------------
Assignee: James Perkins (was: David Lloyd)
> Disable UTF-8 BOM in syslog handler when encoding is undefined
> --------------------------------------------------------------
>
> Key: LOGMGR-98
> URL: https://issues.jboss.org/browse/LOGMGR-98
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Kyle Lape
> Assignee: James Perkins
>
> Section 6.4 MSG: http://tools.ietf.org/html/rfc5424#section-6.4
> bq. If a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. The syslog application MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence.
> While we want to conform to the spec, it is desirable to not include the BOM in some practical applications, e.g. rsyslog does not strip the BOM, and sometimes it would be easier to be able to configure JBoss to not include the BOM than to configure rsyslog to drop it.
> Perhaps we can not include the BOM is the encoding is undefined for the {{SyslogHandler}}, but do include it if the {{encoding}} is explicitly set to {{UTF-8}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months