February 2014 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-84) Configurable default Locale for Logger#getMessageLogger()

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-84?page=com.atlassian.jira.plug... ] David Lloyd resolved JBLOGGING-84. ---------------------------------- Resolution: Rejected Closing as rejected until/unless a viable approach is discovered. > Configurable default Locale for Logger#getMessageLogger() > --------------------------------------------------------- > > Key: JBLOGGING-84 > URL: https://issues.jboss.org/browse/JBLOGGING-84 > Project: JBoss Logging > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Michael Locher > Assignee: David Lloyd > > Please make the Locale for org.jboss.logging.Logger#getMessageLogger configurable (e.g. via a system property). > Use Case: > Having different locales for 'application code' which is deployed in JBAPP (specified as JVM default at startup and available via Locale.getDefault()) and the locale for logging of JBAPP. -- 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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (DROOLS-444) NOT conditional element is broken when used with subnetworks

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-444: ------------------------------------- Summary: NOT conditional element is broken when used with subnetworks Key: DROOLS-444 URL: https://issues.jboss.org/browse/DROOLS-444 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.1.Final, 6.0.0.Final Reporter: Davide Sottara Assignee: Mark Proctor Priority: Critical -- 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-3039) Update to HAL 2.2.0.Beta2

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-3039?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-3039: ------------------------------ Fix Version/s: 8.0.1.Final > Update to HAL 2.2.0.Beta2 > ------------------------- > > Key: WFLY-3039 > URL: https://issues.jboss.org/browse/WFLY-3039 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Blocker > Fix For: 8.0.1.Final > > -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-3039) Update to HAL 2.2.0.Beta2

by Harald Pehl (JIRA)

Harald Pehl created WFLY-3039: --------------------------------- Summary: Update to HAL 2.2.0.Beta2 Key: WFLY-3039 URL: https://issues.jboss.org/browse/WFLY-3039 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Priority: Blocker -- 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

1
0
0 / 0

[JBoss JIRA] (LOGMGR-97) AS6 org.jboss.logmanager.handlers.SizeRotatingFileHandler bug

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-97?page=com.atlassian.jira.plugin.... ] David Lloyd updated LOGMGR-97: ------------------------------ Assignee: James Perkins (was: David Lloyd) > AS6 org.jboss.logmanager.handlers.SizeRotatingFileHandler bug > ------------------------------------------------------------- > > Key: LOGMGR-97 > URL: https://issues.jboss.org/browse/LOGMGR-97 > Project: JBoss Log Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Ivan Chupakhin > Assignee: James Perkins > > method preWrite : > for (int i = maxBackupIndex - 1; i > 1; i--) > { > new File(file.getAbsolutePath() + "." + i).renameTo(new c File(file.getAbsolutePath() + "." + (i - 1))); > } > Logical error while renaming log files, the arguments of renameTo function are passed in the wrong order. -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014