November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-145) A Locale should be used for formatting FormatStyle.PRINTF log records

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-145?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-145: -------------------------------------- Ah good point. I just did a quick look at {{MessageFormat.format()}} static method and it wasn't there. > A Locale should be used for formatting FormatStyle.PRINTF log records > --------------------------------------------------------------------- > > Key: LOGMGR-145 > URL: https://issues.jboss.org/browse/LOGMGR-145 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Priority: Minor > > If the {{FormatStyle.PRINTF}} is used a {{Locale}} should be used in the {{String.format()}} invocation. The locale may be stored in the {{ExtLogRecord}}. Log methods should likely be added to accept the {{Locale}} as a parameter. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1789) PreparedResponseTestCase from wf-core-eap fails intermittently

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1789?page=com.atlassian.jira.plugi... ] Brian Stansberry reopened WFCORE-1789: -------------------------------------- > PreparedResponseTestCase from wf-core-eap fails intermittently > -------------------------------------------------------------- > > Key: WFCORE-1789 > URL: https://issues.jboss.org/browse/WFCORE-1789 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Alpha7 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha9 > > Attachments: firefox.desktop > > > *Description of problem:* > PreparedResponseTestCase from wf-core-eap fails intermittently with two different stack-trace > *How reproducible:* > 2% > *Actual results: (1. issue)* > Stack Trace: > {noformat} > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.wildfly.core.test.standalone.mgmt.PreparedResponseTestCase.reloadServer(PreparedResponseTestCase.java:113) > {noformat} > Standard Output: > {noformat} > &amp#27;[0m01:34:22,658 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment slow-stop.jar (runtime-name: slow-stop.jar) in 3025ms > &amp#27;[0m&amp#27;[0m01:34:22,701 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" stopped in 3071ms > &amp#27;[0m&amp#27;[0m01:34:22,710 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" starting > &amp#27;[0m&amp#27;[0m01:34:23,243 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &amp#27;[0m&amp#27;[0m01:34:23,331 INFO [org.jboss.as.patching] (MSC service thread 1-4) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none > &amp#27;[0m&amp#27;[33m01:34:23,361 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-3) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/testsuite/manualmode/target/wildfly-core/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &amp#27;[0m&amp#27;[33m01:34:23,355 WARN [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console > &amp#27;[0m&amp#27;[0m01:34:23,367 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "slow-stop.jar" (runtime-name: "slow-stop.jar") > &amp#27;[0m&amp#27;[33m01:34:23,449 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.controller:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[33m01:34:23,450 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.server:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[33m01:34:23,452 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.wildfly.extension.request-controller:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[33m01:34:23,453 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.network:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[0m01:34:23,479 INFO [org.wildfly.test.shutdown.SlowStopService] (MSC service thread 1-7) Started with a stop duration of 3000 ms > &amp#27;[0m&amp#27;[0m01:34:23,528 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "slow-stop.jar" (runtime-name : "slow-stop.jar") > &amp#27;[0m > {noformat} > *Actual results: (2. issue)* > Stack Trace: > {noformat} > java.lang.RuntimeException: java.io.IOException: java.util.concurrent.CancellationException: Operation was cancelled > at org.jboss.threads.AsyncFutureTask.operationCancelled(AsyncFutureTask.java:70) > at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:267) > at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:57) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.wildfly.core.testrunner.ManagementClient.executeForResult(ManagementClient.java:234) > at org.wildfly.core.test.standalone.mgmt.PreparedResponseTestCase.reloadServer(PreparedResponseTestCase.java:102) > {noformat} > Standard Output: > {noformat} > 11:03:28,015 WARN [org.jboss.as.protocol.connection] (Remoting "management-client" task-5) WFLYPRT0018: No such request (1) associated with channel Channel ID a37ddd63 (outbound) of Remoting connection 68823cff to /10.16.180.146:9990 of endpoint "management-client" <6645cf9f> > {noformat} > *Expected results:* > No errors > *Additional info:* > Links to jenkins results: > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T... > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-... > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-145) A Locale should be used for formatting FormatStyle.PRINTF log records

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-145?page=com.atlassian.jira.plugin... ] David Lloyd commented on LOGMGR-145: ------------------------------------ MessageFormat also allows a locale to be set. Also, the MessageBundle method(s) use Locale to locate the right bundle. > A Locale should be used for formatting FormatStyle.PRINTF log records > --------------------------------------------------------------------- > > Key: LOGMGR-145 > URL: https://issues.jboss.org/browse/LOGMGR-145 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Priority: Minor > > If the {{FormatStyle.PRINTF}} is used a {{Locale}} should be used in the {{String.format()}} invocation. The locale may be stored in the {{ExtLogRecord}}. Log methods should likely be added to accept the {{Locale}} as a parameter. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-116: ------------------------------------- There are already methods to establish the locale based on the log instance. Passing in a different locale is not going to work well because (for example) if I pass in a French locale to a German log instance, it's still going to come out in German. IOW the locale is locked to the class, which is why using a protected method is the best way to do it. I think it's enough to just put the locale instance in the class. > Locale is not used in the actual string format. > ----------------------------------------------- > > Key: LOGTOOL-116 > URL: https://issues.jboss.org/browse/LOGTOOL-116 > Project: Log Tool > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha1 > > > The {{String.format()}} method accepts a Locale parameter. We should be using the Locale of the implementation class. Since the format method is called from a final method, we need a polymorphic way of getting the Locale instance; therefore, a protected method should be added to the generated base class like this: > {code} > protected Locale getLoggingLocale() { > return Locale.ROOT; > } > {code} > Then each subclass should return a locale object specific to that class. The locale object returned should either be one of the following: > * Locale.CANADA - for "en_CA" > * Locale.CANADA_FRENCH - for "fr_CA" > * Locale.CHINESE - for "zh" > * Locale.ENGLISH - for "en" > * Locale.FRANCE - for "fr_FR" > * Locale.FRENCH - for "fr" > * Locale.GERMAN - for "de" > * Locale.GERMANY - for "de_DE" > * Locale.ITALIAN - for "it" > * Locale.ITALY - for "it_IT" > * Locale.JAPAN - for "ja_JP" > * Locale.JAPANESE - for "ja" > * Locale.KOREA - for "ko_KR" > * Locale.KOREAN - for "ko" > * Locale.SIMPLIFIED_CHINESE - for "zh_CN" > * Locale.TRADITIONAL_CHINESE - for "zh_TW" > * Locale.UK - for "en_GB" > * Locale.US - for "en_US" > If the locale is not one of the above, then the correct Locale should be created in a private constant field of the class like this: > {code} > private static final Locale LOCALE = new Locale("hu"); > // or... > private static final Locale LOCALE = new Locale("hu", "HU"); > // or... > private static final Locale LOCALE = new Locale("hu", "HU", "technl"); > // ...and then... > @Override > protected Locale getLoggingLocale() { > return LOCALE; > } > {code} > Finally, all calls to {{format()}} should be rewritten to use the locale *from the method* like this: > {code} > final NamingException result = new NamingException(String.format(getLoggingLocale(), objectFromReference$str())); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1362) accumulate and over window:time usage will stuck drools for a while (from minutes to hours according to number of facts)

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1362?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1362: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > accumulate and over window:time usage will stuck drools for a while (from minutes to hours according to number of facts) > ------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-1362 > URL: https://issues.jboss.org/browse/DROOLS-1362 > Project: Drools > Issue Type: Bug > Affects Versions: 6.5.0.Final > Reporter: Ertugrul Akbas > Assignee: Mario Fusco > > We are testing a simple rule. The rule is: > import com.anet.correlation.*; > import java.util.*; > import com.anet.ntLog.collector.*; > import com.anet.alarm.*; > import com.anet.util.*; > import com.anet.correlation.operators.*; > import com.anet.correlation.utils.*; > declare EPSObject > @role(event) > > end > rule "test" > when > Number( ) from accumulate( > generalcorrelationobject1:EPSObject(name=='ert', $temp :avg_snmptrapeps) over window:time( 3m ), > average( $temp ) ) > then > end > we are inserting facts continuously and after 3 minutes - the time which is given as "over window:time( 3m )" - > drools stuck and then after minutes , starts to conitinue. > Not: When we test with "over window:time( 30m )" stuck 30 minutes later or When we test with "over window:time( 10m )" stuck 10 minutes later > Any comment? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1362) accumulate and over window:time usage will stuck drools for a while (from minutes to hours according to number of facts)

by Ertugrul Akbas (JIRA)

Ertugrul Akbas created DROOLS-1362: -------------------------------------- Summary: accumulate and over window:time usage will stuck drools for a while (from minutes to hours according to number of facts) Key: DROOLS-1362 URL: https://issues.jboss.org/browse/DROOLS-1362 Project: Drools Issue Type: Bug Affects Versions: 6.5.0.Final Reporter: Ertugrul Akbas Assignee: Edson Tirelli We are testing a simple rule. The rule is: import com.anet.correlation.*; import java.util.*; import com.anet.ntLog.collector.*; import com.anet.alarm.*; import com.anet.util.*; import com.anet.correlation.operators.*; import com.anet.correlation.utils.*; declare EPSObject @role(event) end rule "test" when Number( ) from accumulate( generalcorrelationobject1:EPSObject(name=='ert', $temp :avg_snmptrapeps) over window:time( 3m ), average( $temp ) ) then end we are inserting facts continuously and after 3 minutes - the time which is given as "over window:time( 3m )" - drools stuck and then after minutes , starts to conitinue. Not: When we test with "over window:time( 30m )" stuck 30 minutes later or When we test with "over window:time( 10m )" stuck 10 minutes later Any comment? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-264) avassist.ModuleClassPath throws NoSuchMethodError when running on Jigsaw EA build

by Mandy Chung (JIRA)

[ https://issues.jboss.org/browse/JASSIST-264?page=com.atlassian.jira.plugi... ] Mandy Chung commented on JASSIST-264: ------------------------------------- [~chiba] would you mind checking the version without ModuleClassPath change on Project Jigsaw EA build? This will validate if JASSIST-261 is related to #ClassFilesAsResources. > avassist.ModuleClassPath throws NoSuchMethodError when running on Jigsaw EA build > --------------------------------------------------------------------------------- > > Key: JASSIST-264 > URL: https://issues.jboss.org/browse/JASSIST-264 > Project: Javassist > Issue Type: Bug > Reporter: Mandy Chung > Assignee: Shigeru Chiba > > Project Jigsaw EA build is available for download at > http://openjdk.java.net/projects/jigsaw/ea > The Jigsaw EA build is the latest prototype implementation of JSR 376, the Java Platform Module System, that implements the proposals to resolve the JSR 376 open issues: > http://openjdk.java.net/projects/jigsaw/spec/issues/ > java.lang.NoSuchMethodError: java.lang.reflect.Layer.parent()Ljava/util/Optional; > at javassist.ModuleClassPath.<init>(ModuleClassPath.java:53) > at javassist.ModuleClassPath.<init>(ModuleClassPath.java:39) > at javassist.ClassPoolTail.appendSystemPath(ClassPoolTail.java:249) > at javassist.ClassPool.appendSystemPath(ClassPool.java:944) > at javassist.ClassPool.<init>(ClassPool.java:179) > is calling java.lang.reflect.Layer::parent method. Layer::parent method is not present due to the solution #NonHierarchicalLayers issue. > Looks like ModuleClassPath class is added to resolved JASSIST-261 and unclear why Layer::parent is needed. But looks like this is related to #ClassFilesAsResources issue in JDK 9 that encapsulate .class file from access. > The Jigsaw EA build has resolved #ClassFilesAsResources to allow ClassLoader::getResource* methods to access .class files. Note that this is not in JDK 9 yet. Please subscribe to jigsaw-dev(a)openjdk.java.net for announcement. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-117) Unused import in generated log class

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-117?page=com.atlassian.jira.plugi... ] James Perkins updated LOGTOOL-117: ---------------------------------- Fix Version/s: (was: 2.1.0.Alpha1) > Unused import in generated log class > ------------------------------------ > > Key: LOGTOOL-117 > URL: https://issues.jboss.org/browse/LOGTOOL-117 > Project: Log Tool > Issue Type: Bug > Affects Versions: 2.0.1.Final > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.0.2.Final > > > The class "org.jboss.logging.Logger.Level" is being imported without being used; all references to constants in this class are fully qualified. Either use the import (now that imports are safe, theoretically), or delete it and stick with qualified names. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-145) A Locale should be used for formatting FormatStyle.PRINTF log records

by James Perkins (JIRA)

James Perkins created LOGMGR-145: ------------------------------------ Summary: A Locale should be used for formatting FormatStyle.PRINTF log records Key: LOGMGR-145 URL: https://issues.jboss.org/browse/LOGMGR-145 Project: JBoss Log Manager Issue Type: Enhancement Reporter: James Perkins Priority: Minor If the {{FormatStyle.PRINTF}} is used a {{Locale}} should be used in the {{String.format()}} invocation. The locale may be stored in the {{ExtLogRecord}}. Log methods should likely be added to accept the {{Locale}} as a parameter. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-125) Add log methods that accept a Locale for formatting

by James Perkins (JIRA)

James Perkins created JBLOGGING-125: --------------------------------------- Summary: Add log methods that accept a Locale for formatting Key: JBLOGGING-125 URL: https://issues.jboss.org/browse/JBLOGGING-125 Project: JBoss Logging Issue Type: Enhancement Reporter: James Perkins Assignee: James Perkins Priority: Minor When formatting log messages with {{String.format()}} should allow for a {{Locale}} to be passed in and as a parameter defaulting to {{Locale.ROOT}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 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 November 2016