[JBoss JIRA] (WFLY-12390) Hot-Deploy throws IllegalStateException: Timer already cancelled
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12390?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-12390:
-----------------------------------
Does it happy when you package and deploy it as an ejb jar, instead of a war?
> Hot-Deploy throws IllegalStateException: Timer already cancelled
> ----------------------------------------------------------------
>
> Key: WFLY-12390
> URL: https://issues.jboss.org/browse/WFLY-12390
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 17.0.1.Final
> Environment: any OS
> single Wildfly 17 (not yet in production)
> Reporter: David Schmidt
> Assignee: Cheng Fang
> Priority: Major
>
> I did an Upgrade from 11 to 17.0.1 and now I'm getting IllegalStateException on hot-deploys.
> What I tried without result:
> * truncate the jboss_ejb_timer table (to remove existing)
> * remove all old @Schedule and add a new different timer
> * use @Resource TimerService instead of @Schedule
> restart allows to deploy again (for a time)
> {code}
> 2019-08-16 16:13:14,940 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."xxxxxxx.war".component.CronJobs.START: org.jboss.msc.service.Star
> tException in service jboss.deployment.unit."xxxxxxx.war".component.CronJobs.START: java.lang.IllegalStateException: Timer already cancelled.
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: Timer already cancelled.
> at java.util.Timer.sched(Timer.java:397)
> at java.util.Timer.schedule(Timer.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.scheduleTimeout(TimerServiceImpl.java:906)
> at org.jboss.as.ejb3.timerservice.TimerImpl.scheduleTimeout(TimerImpl.java:537)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:785)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:756)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:136)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 8 more
> {code}
> As it happens in programming, I can't reproduce this at the moment. I got tormented for weeks but today it doesn't happen...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4612) Dependency on javaee.api by ExternalModuleDependencySpecService should be optional
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4612?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4612:
-------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3907 (was: https://github.com/wildfly/wildfly-core/pull/3906)
> Dependency on javaee.api by ExternalModuleDependencySpecService should be optional
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4612
> URL: https://issues.jboss.org/browse/WFCORE-4612
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> The module spec for any module created by ExternalModuleSpecService has a dependency on javaee.api added. That should be an optional dependency, allowing this feature to be used in slimmed servers that may not have the javaee.api module installed.
> It seems it's pretty easy to provision such a server, as that module is not heavily depended on:
> {code}
> $ git grep javaee.api | grep module.xml | grep -v src/test
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml: <module name="javaee.api"/>
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml: reexported by javaee.api. -->
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml:<module xmlns="urn:jboss:module:1.5" name="javaee.api">
> feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml: <module name="javaee.api"/>
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml: <module name="javaee.api"/>
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml: reexported by javaee.api. -->
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml: <module name="javaee.api"/>
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml: reexported by javaee.api. -->
> {code}
> JavaEEDependencyProcessor in WildFly explicitly does not add javaee.api as a dep.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12393) The jberet-core module should not depend on the javaee.api module
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12393:
---------------------------------------
Summary: The jberet-core module should not depend on the javaee.api module
Key: WFLY-12393
URL: https://issues.jboss.org/browse/WFLY-12393
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: Brian Stansberry
Assignee: Cheng Fang
The javaee.api module is just a convenience wrapper around the various EE API modules it depends on and exports. The org.jberet.jberet-core module depends on this; it should be updated to depend on the specific APIs it need.
Depending on javaee.api is problematic because in a server that has been slimmed using Galleon we only want to depend on modules that are actually needed and not pull in other API.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12392) JSF modules should not depend on javaee.api
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12392:
---------------------------------------
Summary: JSF modules should not depend on javaee.api
Key: WFLY-12392
URL: https://issues.jboss.org/browse/WFLY-12392
Project: WildFly
Issue Type: Bug
Components: JSF
Reporter: Brian Stansberry
Assignee: Farah Juma
The javaee.api module is just a convenience wrapper around the various EE API modules it depends on and exports. There are 3 JSF modules that depend on this; those should be updated to depend on the specific APIs they need.
Depending on javaee.api is problematic because in a server that has been slimmed using Galleon we only want to depend on modules that are actually needed and not pull in other API.
The problematic modules:
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs
by Nick Sawadsky (Jira)
[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky edited comment on JGRP-2274 at 8/19/19 6:52 PM:
--------------------------------------------------------------
[~belaban] I'm trying to better understand this change.
{quote}decryption of a message will fail if the contents have been changed{quote}
As far as I know, that is not true of all encryption algorithms. Some encryption algorithms have integrity checking built-in, but not all.
For example, the default AES mode in Java is ECB, which does not do any integrity checking. Whereas the GCM mode does perform integrity checking, so that decryption will fail if the message has been tampered with.
I realize that a naive modification will probably quickly result in an error of some kind. But I want to make sure I'm not missing something -- is there some check in the code that will immediately detect if a message has been tampered with by an attacker?
was (Author: nsawadsky):
[~belaban] Trying to better understand this change.
{quote}decryption of a message will fail if the contents have been changed{quote}
As far as I know, that is not true of all encryption algorithms. Some encryption algorithms have integrity checking built-in, but not all.
For example, the default AES mode in Java is ECB, which does not do any integrity checking. Whereas the GCM mode does perform integrity checking, so that decryption will fail if the message has been tampered with.
I realize that a naive modification will probably quickly result in an error of some kind. But I want to make sure I'm not missing something -- is there some check in the code that will immediately detect if a message has been tampered with by an attacker?
> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
> Key: JGRP-2274
> URL: https://issues.jboss.org/browse/JGRP-2274
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs
by Nick Sawadsky (Jira)
[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky edited comment on JGRP-2274 at 8/19/19 6:51 PM:
--------------------------------------------------------------
[~belaban] Trying to better understand this change.
{quote}decryption of a message will fail if the contents have been changed{quote}
As far as I know, that is not true of all encryption algorithms. Some encryption algorithms have integrity checking built-in, but not all.
For example, the default AES mode in Java is ECB, which does not do any integrity checking. Whereas the GCM mode does perform integrity checking, so that decryption will fail if the message has been tampered with.
I realize that a naive modification will probably quickly result in an error of some kind. But I want to make sure I'm not missing something -- is there some check in the code that will immediately detect if a message has been tampered with by an attacker?
was (Author: nsawadsky):
[~belaban] Just a quick comment on this change.
{quote}decryption of a message will fail if the contents have been changed{quote}
As far as I know, that is not true of all encryption algorithms. Some encryption algorithms have integrity checking built-in, but not all.
For example, the default AES mode in Java is ECB, which does not do any integrity checking. Whereas the GCM mode does perform integrity checking, so that decryption will fail if the message has been tampered with.
I realize that a naive modification will probably quickly result in an error of some kind. But I want to make sure I'm not missing something -- is there some check in the code that will immediately detect if a message has been tampered with by an attacker?
> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
> Key: JGRP-2274
> URL: https://issues.jboss.org/browse/JGRP-2274
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs
by Nick Sawadsky (Jira)
[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky commented on JGRP-2274:
-------------------------------------
[~belaban] Just a quick comment on this change.
{quote}decryption of a message will fail if the contents have been changed{quote}
As far as I know, that is not true of all encryption algorithms. Some encryption algorithms have integrity checking built-in, but not all.
For example, the default AES mode in Java is ECB, which does not do any integrity checking. Whereas the GCM mode does perform integrity checking, so that decryption will fail if the message has been tampered with.
I realize that a naive modification will probably quickly result in an error of some kind. But I want to make sure I'm not missing something -- is there some check in the code that will immediately detect if a message has been tampered with by an attacker?
> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
> Key: JGRP-2274
> URL: https://issues.jboss.org/browse/JGRP-2274
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4613) Illegal character use passes the valition on discovery provider uri but fails on server boot
by Radoslav Husar (Jira)
Radoslav Husar created WFCORE-4613:
--------------------------------------
Summary: Illegal character use passes the valition on discovery provider uri but fails on server boot
Key: WFCORE-4613
URL: https://issues.jboss.org/browse/WFCORE-4613
Project: WildFly Core
Issue Type: Bug
Components: Discovery
Affects Versions: 10.0.0.Beta3
Reporter: Radoslav Husar
Assignee: Paul Ferraro
{noformat}
[standalone@localhost:9990 /] /subsystem=discovery/static-provider=mod_cluster:write-attribute(name=services,value=[{uri=mod_cluster:http://localhost:8090},{abstract-type=mod_cluster,uri=http://localhost:8090}]
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] reload
Failed to establish connection in 6014ms
{noformat}
yields
{noformat}
00:05:43,104 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 48) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "discovery"),
("static-provider" => "mod_cluster")
]): java.lang.IllegalArgumentException: Illegal character in scheme name at index 3: mod_cluster:http://localhost:8090
at java.net.URI.create(URI.java:852)
at org.wildfly.extension.discovery.StaticDiscoveryProviderAddHandler.performRuntime(StaticDiscoveryProviderAddHandler.java:60)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:159)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.net.URISyntaxException: Illegal character in scheme name at index 3: mod_cluster:http://localhost:8090
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parse(URI.java:3048)
at java.net.URI.<init>(URI.java:588)
at java.net.URI.create(URI.java:850)
... 12 more
...
00:05:43,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem discovery boot operations"
00:05:43,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem discovery boot operations\""
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4613) Illegal character use passes the validation on discovery provider uri but fails on server boot
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFCORE-4613?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-4613:
-----------------------------------
Summary: Illegal character use passes the validation on discovery provider uri but fails on server boot (was: Illegal character use passes the valition on discovery provider uri but fails on server boot)
> Illegal character use passes the validation on discovery provider uri but fails on server boot
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-4613
> URL: https://issues.jboss.org/browse/WFCORE-4613
> Project: WildFly Core
> Issue Type: Bug
> Components: Discovery
> Affects Versions: 10.0.0.Beta3
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Critical
>
> {noformat}
> [standalone@localhost:9990 /] /subsystem=discovery/static-provider=mod_cluster:write-attribute(name=services,value=[{uri=mod_cluster:http://localhost:8090},{abstract-type=mod_cluster,uri=http://localhost:8090}]
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] reload
> Failed to establish connection in 6014ms
> {noformat}
> yields
> {noformat}
> 00:05:43,104 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 48) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "discovery"),
> ("static-provider" => "mod_cluster")
> ]): java.lang.IllegalArgumentException: Illegal character in scheme name at index 3: mod_cluster:http://localhost:8090
> at java.net.URI.create(URI.java:852)
> at org.wildfly.extension.discovery.StaticDiscoveryProviderAddHandler.performRuntime(StaticDiscoveryProviderAddHandler.java:60)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:159)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.net.URISyntaxException: Illegal character in scheme name at index 3: mod_cluster:http://localhost:8090
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parse(URI.java:3048)
> at java.net.URI.<init>(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 12 more
> ...
> 00:05:43,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem discovery boot operations"
> 00:05:43,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem discovery boot operations\""
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFCORE-4613) Illegal character use doesn't fail validation on discovery provider uri write but fails on server boot
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFCORE-4613?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-4613:
-----------------------------------
Summary: Illegal character use doesn't fail validation on discovery provider uri write but fails on server boot (was: Illegal character use passes the validation on discovery provider uri but fails on server boot)
> Illegal character use doesn't fail validation on discovery provider uri write but fails on server boot
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4613
> URL: https://issues.jboss.org/browse/WFCORE-4613
> Project: WildFly Core
> Issue Type: Bug
> Components: Discovery
> Affects Versions: 10.0.0.Beta3
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Critical
>
> {noformat}
> [standalone@localhost:9990 /] /subsystem=discovery/static-provider=mod_cluster:write-attribute(name=services,value=[{uri=mod_cluster:http://localhost:8090},{abstract-type=mod_cluster,uri=http://localhost:8090}]
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] reload
> Failed to establish connection in 6014ms
> {noformat}
> yields
> {noformat}
> 00:05:43,104 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 48) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "discovery"),
> ("static-provider" => "mod_cluster")
> ]): java.lang.IllegalArgumentException: Illegal character in scheme name at index 3: mod_cluster:http://localhost:8090
> at java.net.URI.create(URI.java:852)
> at org.wildfly.extension.discovery.StaticDiscoveryProviderAddHandler.performRuntime(StaticDiscoveryProviderAddHandler.java:60)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:159)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.net.URISyntaxException: Illegal character in scheme name at index 3: mod_cluster:http://localhost:8090
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parse(URI.java:3048)
> at java.net.URI.<init>(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 12 more
> ...
> 00:05:43,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem discovery boot operations"
> 00:05:43,164 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem discovery boot operations\""
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months