[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
[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
[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
[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