February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBAS-9542) Log file jboss.log gets truncated after restarting the server

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBAS-9542?page=com.atlassian.jira.plugin.... ] David Lloyd resolved JBAS-9542. ------------------------------- Resolution: Done This issue was fixed in JBoss LogManager some time ago. At this time it doesn't seem useful to backport the component upgrade though, if it wasn't already done. > Log file jboss.log gets truncated after restarting the server > ------------------------------------------------------------- > > Key: JBAS-9542 > URL: https://issues.jboss.org/browse/JBAS-9542 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Affects Versions: 6.1.0 > Environment: Windows, Linux > Reporter: Sergey Goldberg > Assignee: David Lloyd > Labels: jboss > > Every time the server is restarted its log file jboss.log gets truncated even when the "append" property is set to true (handler.FILE.append=true) in the logging.properties file. -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ] David Lloyd moved WFLY-1215 to JBVFS-194: ----------------------------------------- Project: JBoss VFS (was: WildFly) Key: JBVFS-194 (was: WFLY-1215) Workflow: classic default workflow (was: GIT Pull Request workflow ) Component/s: (was: VFS) > Clean the status of testing jars for jboss-vfs > ---------------------------------------------- > > Key: JBVFS-194 > URL: https://issues.jboss.org/browse/JBVFS-194 > Project: JBoss VFS > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Marek Goldmann > Assignee: David Lloyd > > There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior. > What's the status of following files? Who wrote them and what is the license of those and where is the upstream code? > ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar > ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar > Can they be replaced with something dummy? -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned JBVFS-194: --------------------------------- Assignee: Ales Justin (was: David Lloyd) Aleš, would you mind fixing or removing these tests please? Thank you. > Clean the status of testing jars for jboss-vfs > ---------------------------------------------- > > Key: JBVFS-194 > URL: https://issues.jboss.org/browse/JBVFS-194 > Project: JBoss VFS > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Marek Goldmann > Assignee: Ales Justin > > There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior. > What's the status of following files? Who wrote them and what is the license of those and where is the upstream code? > ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar > ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar > Can they be replaced with something dummy? -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ] David Lloyd updated JBVFS-194: ------------------------------ Priority: Critical (was: Major) > Clean the status of testing jars for jboss-vfs > ---------------------------------------------- > > Key: JBVFS-194 > URL: https://issues.jboss.org/browse/JBVFS-194 > Project: JBoss VFS > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Marek Goldmann > Assignee: Ales Justin > Priority: Critical > > There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior. > What's the status of following files? Who wrote them and what is the license of those and where is the upstream code? > ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar > ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar > Can they be replaced with something dummy? -- 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

10 years, 9 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 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

10 years, 9 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

10 years, 9 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

10 years, 9 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

10 years, 9 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

10 years, 9 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

10 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014