October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-52) Add option to WriterHandler to collapse repeated messages

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-52?page=com.atlassian.jira.plugin.... ] James Perkins updated LOGMGR-52: -------------------------------- Fix Version/s: 2.1.0.Alpha6 (was: 2.1.0.Alpha5) > Add option to WriterHandler to collapse repeated messages > --------------------------------------------------------- > > Key: LOGMGR-52 > URL: https://issues.jboss.org/browse/LOGMGR-52 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 2.1.0.Alpha6 > > > The WriterHandler could have a time interval configured wherein a repeated message would be collapsed. > The last message would be stored in a field for comparison along with a nanoTime tag (the timestamp on the message is not adequate because the clock can have skew or be reset completely at any time). If the current message string equals the last message string, and collapsing is enabled, then instead of logging the message, a count is incremented. If the current message is not equal, then the stored message is logged with a tag indicating the number of repeats (i18n?) and then the next submitted message is logged. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-134) Add module name, module version fields to ExtLogRecord

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-134?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-134: --------------------------------- Fix Version/s: 2.1.0.Alpha6 (was: 2.1.0.Alpha5) > Add module name, module version fields to ExtLogRecord > ------------------------------------------------------ > > Key: LOGMGR-134 > URL: https://issues.jboss.org/browse/LOGMGR-134 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 2.1.0.Alpha6 > > > It will be necessary for ExtLogRecord to carry additional fields for Java 9 module name and module version. The serialization impact should be analyzed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-133) Use StackWalker to get extended log record information

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-133?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-133: --------------------------------- Fix Version/s: 2.1.0.Alpha6 (was: 2.1.0.Alpha5) > Use StackWalker to get extended log record information > ------------------------------------------------------ > > Key: LOGMGR-133 > URL: https://issues.jboss.org/browse/LOGMGR-133 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 2.1.0.Alpha6 > > > Under Java 9, you can use a StackWalker to efficiently traverse the stack and return information about callers. Using this mechanism should be substantially better-performing than snapshotting the stack to acquire the calling class information for the extended log record class. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-132) Remove extended stack trace functionality

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-132?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-132: --------------------------------- Fix Version/s: 2.1.0.Alpha6 (was: 2.1.0.Alpha5) > Remove extended stack trace functionality > ----------------------------------------- > > Key: LOGMGR-132 > URL: https://issues.jboss.org/browse/LOGMGR-132 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 2.1.0.Alpha6 > > > Java 9 stack traces include module name and version number. All our extended stack trace hacky code should be deleted and both format characters should yield a standard stack trace under Java 9. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-131) Add format characters for module name, module version

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-131: --------------------------------- Fix Version/s: 2.1.0.Alpha6 (was: 2.1.0.Alpha5) > Add format characters for module name, module version > ----------------------------------------------------- > > Key: LOGMGR-131 > URL: https://issues.jboss.org/browse/LOGMGR-131 > Project: JBoss Log Manager > Issue Type: Sub-task > Reporter: David Lloyd > Fix For: 2.1.0.Alpha6 > > > In JDK9, StackTraceElements contain moduleName and moduleVersion fields. This information is useful for debugging purposes, thus format characters should be allocated towards these values. Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-130) JDK9 Support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-130?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-130: --------------------------------- Fix Version/s: 2.1.0.Alpha6 (was: 2.1.0.Alpha5) > JDK9 Support > ------------ > > Key: LOGMGR-130 > URL: https://issues.jboss.org/browse/LOGMGR-130 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: David Lloyd > Fix For: 2.1.0.Alpha6 > > > A few enhancements become possible, desirable, and/or necessary when moving to JDK 9. This is an umbrella parent issue to cover them all. > Note that some of these features may require multi-version JAR building, which Maven cannot yet do. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-86) Create an exception filter

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-86?page=com.atlassian.jira.plugin.... ] James Perkins updated LOGMGR-86: -------------------------------- Fix Version/s: 2.1.0.Alpha6 (was: 2.1.0.Alpha5) > Create an exception filter > -------------------------- > > Key: LOGMGR-86 > URL: https://issues.jboss.org/browse/LOGMGR-86 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: James Perkins > Fix For: 2.1.0.Alpha6 > > > For now this is just a thought so that users can filter messages based on an exception in the stack trace. Currently it's not possible to use a regex filter as the stack trace is not used in when testing for matches and it probably shouldn't be used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9419) Infinispan subsystem returns wrong value for GlobalConfiguration.transport().clusterName()

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9419?page=com.atlassian.jira.plugin.... ] Paul Ferraro moved JBEAP-13368 to WFLY-9419: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9419 (was: JBEAP-13368) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 11.0.0.CR1 (was: 7.1.0.CR2) > Infinispan subsystem returns wrong value for GlobalConfiguration.transport().clusterName() > ------------------------------------------------------------------------------------------ > > Key: WFLY-9419 > URL: https://issues.jboss.org/browse/WFLY-9419 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > This prevents users from easily creating multiple clusters on the same network whose nodes need to interact with each other via the ejb client. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3332) Chained transformers don't work correctly if an earlier transformer in the chain converts an op into a composite

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3332: ---------------------------------------- Summary: Chained transformers don't work correctly if an earlier transformer in the chain converts an op into a composite Key: WFCORE-3332 URL: https://issues.jboss.org/browse/WFCORE-3332 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry CompositeOperationTransformer doesn't work correctly if the resource against which transformation is occurring isn't the root. It asserts that it is the root, and therefore fails. And if that is corrected, then it passes an absolute address to a method that builds an absolute PathAddress from a relative one, instead of using the method that takes an absolute address. Where I'm seeing this fail is with a chained transformer, where the first link in the chain converts an op into a composite. The op is not against the root, so the address of the resource being transformed also isn't. As the chain proceeds, CompositeOperationTransformer gets called and blows up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3331) Missing or redundant license for org.wildfly.core:wildfly-elytron-integration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3331?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3331: ------------------------------------- Security: (was: Red Hat Internal) > Missing or redundant license for org.wildfly.core:wildfly-elytron-integration > ----------------------------------------------------------------------------- > > Key: WFCORE-3331 > URL: https://issues.jboss.org/browse/WFCORE-3331 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.3.Final, 3.0.4.Final > Reporter: Petr Sakař > Assignee: Petr Sakař > Priority: Critical > > licenses.xml contains: > {code} > <licenses> > <license> > <name>GNU Lesser General Public License v2.1 or later</name> > <url>http://www.gnu.org/licenses/old-licenses/lgpl-2.1-standalone.html</url> > <distribution>repo</distribution> > </license> > <license> > <name>Apache License 2.0</name> > <url>http://www.apache.org/licenses/LICENSE-2.0</url> > <distribution>repo</distribution> > </license> > </licenses> > {code} > However, wildfly-elytron-integration-3.0.3.Final.pom only contains: > {code} > <licenses> > <license> > <name>Apache 2</name> > <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> > <distribution>repo</distribution> > </license> > </licenses> > {code} > Please fix either licenses.xml or pom. > In case the pom is fixed, please use {{Apache License 2.0}} instead of {{Apache 2}} as license name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017