[JBoss JIRA] (LOGTOOL-120) Locale is not used in the actual string format.
by James Perkins (JIRA)
James Perkins created LOGTOOL-120:
-------------------------------------
Summary: Locale is not used in the actual string format.
Key: LOGTOOL-120
URL: https://issues.jboss.org/browse/LOGTOOL-120
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, 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, 5 months
[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
James Perkins reopened LOGTOOL-116:
-----------------------------------
> 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.0.2.Final, 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, 5 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2011:
------------------------------------------
I don't think this is a bug, at least not in terms of CLI use. I haven't thought about how the console presents the data.
This is the output of read-resource when you don't ask the server to give you default values for undefined attributes:
{code}
[standalone@embedded console-handler=CONSOLE] :read-resource(include-defaults=false)
{
"outcome" => "success",
"result" => {
"autoflush" => undefined,
"enabled" => undefined,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => undefined,
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => undefined
}
}
{code}
When you do a simple read-resource you get the default values. That's general server-wide behavior and isn't going to be modified for this particular case.
The 'formatter' and 'named-formatter' attributes are marked as alternatives to each other, so the attribute descriptions make clear that the user can only define one or the other. The one that is defined is the one that takes effect.
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
> It is working as it is defined with colors in a console.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
> It should be fixed like below:
> {code:title=Expected result}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => undefined,
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGTOOL-116) Locale is not used in the actual string format.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-116?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-116:
----------------------------------
Git Pull Request: https://github.com/jboss-logging/jboss-logging-tools/pull/56, https://github.com/jboss-logging/jboss-logging-tools/pull/57 (was: https://github.com/jboss-logging/jboss-logging-tools/pull/56)
> 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.0.2.Final, 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, 5 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
ted won updated WFCORE-2011:
----------------------------
Description:
In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
It is working as it is defined with colors in a console.
{code:title=standalone.xml}
...
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
...
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
</formatter>
</subsystem>
...
{code}
However there is a inconsistency in the CLI and WildFly admin console views.
In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
{code:title=JBoss CLI}
[standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}
}
{code}
It should be fixed like below:
{code:title=Expected result}
[standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => undefined,
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}
}
{code}
was:
In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
And the COLOR-PATTERN named-formatter is defined with {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n".{noformat}
It is working as it is defined with colors.
{code:title=standalone.xml}
...
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
...
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
</formatter>
</subsystem>
...
{code}
However there is a inconsistency in the CLI and WildFly admin console views.
{noformat}
In the CLI, CONSOLE formatter is "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n". It is different with the working logging format.
{noformat}
{code:title=JBoss CLI}
[standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}
}
{code}
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
> It is working as it is defined with colors in a console.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
> It should be fixed like below:
> {code:title=Expected result}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => undefined,
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7630) Public singleton API is not binary compatible with WF10
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7630?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-7410 to WFLY-7630:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7630 (was: JBEAP-7410)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: No Release
(was: 7.1.0.DR8)
> Public singleton API is not binary compatible with WF10
> -------------------------------------------------------
>
> Key: WFLY-7630
> URL: https://issues.jboss.org/browse/WFLY-7630
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> The public singleton API changed recently and is not binary compatible any more.
> The change was introduced by: https://github.com/jbossas/jboss-eap7/pull/907/files#diff-dac46a30e73e80f...
> [SingletonPolicy.java|https://github.com/jbossas/jboss-eap7/blob/7.x/clust...] has changed:
> Now:
> {code}
> <T> SingletonBuilder<T> createSingletonServiceBuilder(ServiceName name, Service<T> service);
> {code}
> Before:
> {code}
> <T> Builder<T> createSingletonServiceBuilder(ServiceName name, Service<T> service);
> {code}
> The change is source compatible, however not binary compatible.
> This results in NoSuchMethodError:
> {code}
> [JBossINF] [0m[31m02:26:32,982 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."SStest-ejb-service-activator.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."SStest-ejb-service-activator.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "SStest-ejb-service-activator.jar"
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.lang.NoSuchMethodError: org.wildfly.clustering.singleton.SingletonPolicy.createSingletonServiceBuilder(Lorg/jboss/msc/service/ServiceName;Lorg/jboss/msc/service/Service;)Lorg/wildfly/clustering/service/Builder;
> [JBossINF] at org.jboss.test.singletonservice.SingletonActivator.activate(SingletonActivator.java:29)
> [JBossINF] at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> [JBossINF] ... 5 more
> {code}
> Link to the server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7630) Public singleton API is not binary compatible with WF10
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7630?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-7630:
-------------------------------
Fix Version/s: 11.0.0.Alpha1
> Public singleton API is not binary compatible with WF10
> -------------------------------------------------------
>
> Key: WFLY-7630
> URL: https://issues.jboss.org/browse/WFLY-7630
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> The public singleton API changed recently and is not binary compatible any more.
> The change was introduced by: https://github.com/jbossas/jboss-eap7/pull/907/files#diff-dac46a30e73e80f...
> [SingletonPolicy.java|https://github.com/jbossas/jboss-eap7/blob/7.x/clust...] has changed:
> Now:
> {code}
> <T> SingletonBuilder<T> createSingletonServiceBuilder(ServiceName name, Service<T> service);
> {code}
> Before:
> {code}
> <T> Builder<T> createSingletonServiceBuilder(ServiceName name, Service<T> service);
> {code}
> The change is source compatible, however not binary compatible.
> This results in NoSuchMethodError:
> {code}
> [JBossINF] [0m[31m02:26:32,982 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."SStest-ejb-service-activator.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."SStest-ejb-service-activator.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "SStest-ejb-service-activator.jar"
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.lang.NoSuchMethodError: org.wildfly.clustering.singleton.SingletonPolicy.createSingletonServiceBuilder(Lorg/jboss/msc/service/ServiceName;Lorg/jboss/msc/service/Service;)Lorg/wildfly/clustering/service/Builder;
> [JBossINF] at org.jboss.test.singletonservice.SingletonActivator.activate(SingletonActivator.java:29)
> [JBossINF] at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:91)
> [JBossINF] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> [JBossINF] ... 5 more
> {code}
> Link to the server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Eder F. Freitas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Eder F. Freitas edited comment on WFLY-6561 at 11/18/16 2:38 PM:
-----------------------------------------------------------------
This error is still happening in Wildfly 10.1.0, SUSE operating system, do you need any more information about it?
{noformat}
2016-11-18 17:28:00,002 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=e1bdd4d5-93e9-44e5-a8e1-7f196aa9e935 timedObjectId=prati.supervisorio.nobreaks.supervisorio.nobreaks-ejb.MonitoramentoProcess auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@4c67a17f initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Fri Nov 18 17:28:00 BRST 2016 timerState=IN_TIMEOUT info=NOBREAK_SEM_BANCO_UPS] is still in progress, skipping this overlapping scheduled execution at: Fri Nov 18 17:28:00 BRST 2016.
{noformat}
was (Author: eder.freitas):
This error is still happening in Wildfly 10.1.0, SUSE operating system, do you need any more information about it?
{panel:title=My title}
2016-11-18 17:28:00,002 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=e1bdd4d5-93e9-44e5-a8e1-7f196aa9e935 timedObjectId=prati.supervisorio.nobreaks.supervisorio.nobreaks-ejb.MonitoramentoProcess auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@4c67a17f initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Fri Nov 18 17:28:00 BRST 2016 timerState=IN_TIMEOUT info=NOBREAK_SEM_BANCO_UPS] is still in progress, skipping this overlapping scheduled execution at: Fri Nov 18 17:28:00 BRST 2016.
{panel}
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Eder F. Freitas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Eder F. Freitas edited comment on WFLY-6561 at 11/18/16 2:37 PM:
-----------------------------------------------------------------
This error is still happening in Wildfly 10.1.0, SUSE operating system, do you need any more information about it?
{code:java}
2016-11-18 17:28:00,002 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=e1bdd4d5-93e9-44e5-a8e1-7f196aa9e935 timedObjectId=prati.supervisorio.nobreaks.supervisorio.nobreaks-ejb.MonitoramentoProcess auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@4c67a17f initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Fri Nov 18 17:28:00 BRST 2016 timerState=IN_TIMEOUT info=NOBREAK_SEM_BANCO_UPS] is still in progress, skipping this overlapping scheduled execution at: Fri Nov 18 17:28:00 BRST 2016.
{code}
was (Author: eder.freitas):
This error is still happening in Wildfly 10.1.0, SUSE operating system, do you need any more information about it?
{{2016-11-18 17:28:00,002 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=e1bdd4d5-93e9-44e5-a8e1-7f196aa9e935 timedObjectId=prati.supervisorio.nobreaks.supervisorio.nobreaks-ejb.MonitoramentoProcess auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@4c67a17f initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Fri Nov 18 17:28:00 BRST 2016 timerState=IN_TIMEOUT info=NOBREAK_SEM_BANCO_UPS] is still in progress, skipping this overlapping scheduled execution at: Fri Nov 18 17:28:00 BRST 2016.
}}
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Eder F. Freitas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Eder F. Freitas edited comment on WFLY-6561 at 11/18/16 2:37 PM:
-----------------------------------------------------------------
This error is still happening in Wildfly 10.1.0, SUSE operating system, do you need any more information about it?
{panel:title=My title}
2016-11-18 17:28:00,002 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=e1bdd4d5-93e9-44e5-a8e1-7f196aa9e935 timedObjectId=prati.supervisorio.nobreaks.supervisorio.nobreaks-ejb.MonitoramentoProcess auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@4c67a17f initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Fri Nov 18 17:28:00 BRST 2016 timerState=IN_TIMEOUT info=NOBREAK_SEM_BANCO_UPS] is still in progress, skipping this overlapping scheduled execution at: Fri Nov 18 17:28:00 BRST 2016.
{panel}
was (Author: eder.freitas):
This error is still happening in Wildfly 10.1.0, SUSE operating system, do you need any more information about it?
{code:java}
2016-11-18 17:28:00,002 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=e1bdd4d5-93e9-44e5-a8e1-7f196aa9e935 timedObjectId=prati.supervisorio.nobreaks.supervisorio.nobreaks-ejb.MonitoramentoProcess auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@4c67a17f initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Fri Nov 18 17:28:00 BRST 2016 timerState=IN_TIMEOUT info=NOBREAK_SEM_BANCO_UPS] is still in progress, skipping this overlapping scheduled execution at: Fri Nov 18 17:28:00 BRST 2016.
{code}
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months