[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Petr Kremensky commented on WFCORE-1682:
----------------------------------------
One more issue with completion I didn't notice before is that argument is suggested multiple times
{noformat}
[disconnected /] patch rollback --patch-id=my-custom-patch --p<TAB>
--patch-id --patch-stream= --preserve=
{noformat}
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFBUILD-14) Conflicting feature pack dependency versions should not be allowed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin... ]
Thomas Diesler edited comment on WFBUILD-14 at 8/2/16 7:04 AM:
---------------------------------------------------------------
This condition still seems to be silently ignored both by the feature-pack-build and the server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
What is supposed to happen here?
The server-provisioning plugin could enforce the exact same version of transitively reachable features packs or use semantic versioning to choose the latest compatible. The former approach would work every time. The latter would likely work in most cases while eliminating the need to rebuild dependent feature packs.
If you like, I could take a look at this.
was (Author: thomas.diesler):
This condition still seems to be silently ignored both by the feature-pack-build and the server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
> Conflicting feature pack dependency versions should not be allowed
> ------------------------------------------------------------------
>
> Key: WFBUILD-14
> URL: https://issues.jboss.org/browse/WFBUILD-14
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: James Netherton
> Assignee: Stuart Douglas
> Fix For: 1.1.7.Final
>
>
> There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
> Consider the following.
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
> {code}
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> <artifact name="org.foo:feature-pack-A" />
> </dependencies>
> {code}
> The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
> At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFBUILD-14) Conflicting feature pack dependency versions should not be allowed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin... ]
Thomas Diesler reopened WFBUILD-14:
-----------------------------------
This condition still seems to be silently ignored both by the feature-pack-build and the server-provisioning plugin.
On server start I see
{code}
12:43:56,173 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.10.Final "Kenny" starting
12:43:56,730 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.0.10.Final.jar:2.0.10.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
Message: Unexpected element '{urn:jboss:domain:4.2}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
... 3 more
12:43:56,734 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
> Conflicting feature pack dependency versions should not be allowed
> ------------------------------------------------------------------
>
> Key: WFBUILD-14
> URL: https://issues.jboss.org/browse/WFBUILD-14
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: James Netherton
> Assignee: Stuart Douglas
> Fix For: 1.1.7.Final
>
>
> There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
> Consider the following.
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
> {code}
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> <artifact name="org.foo:feature-pack-A" />
> </dependencies>
> {code}
> The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
> At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
The side effects of WFCORE-1487 are actually in completion too. There is now a mismatch in the completion logic between indexed and named arguments.
For example: edit-batch-line --line-number=1 :<TAB>
the completer for the line-number (null) is returned instead of the completer for the line.
- The documentation of the commands have not been updated to reflect that the arguments names can be used (look at connect help for example).
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6904) Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6904:
------------------------------------
Summary: Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
Key: WFLY-6904
URL: https://issues.jboss.org/browse/WFLY-6904
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final, 10.1.0.CR1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: 11.0.0.Alpha1, 11.0.0.Beta1
To reproduce run e.g.
{noformat}
/subsystem=undertow/servlet-container=default/setting=session-cookie:add(http-only=true)
{noformat}
yields NPE when registering with the proxy
{noformat}2016-08-01 14:42:20,623 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to apache-server/10.0.0.1:6666, configuration will be reset: MEM: Can't read node
2016-08-01 14:42:30,626 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) null: java.lang.NullPointerException
at org.jboss.modcluster.mcmp.impl.DefaultMCMPRequestFactory.createConfigRequest(DefaultMCMPRequestFactory.java:128)
at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:89)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:399)
at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457)
at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6903) Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6903:
---------------------------------
Workaround Description:
For wokaround set the cookie name explicitly via e.g.:
{code}/subsystem=undertow/servlet-container=default/setting=session-cookie:write-attribute(name=name,value=JSESSIONID{code}
Forum Reference: https://developer.jboss.org/message/960888?et=watches.email.thread#960888
> Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6903
> URL: https://issues.jboss.org/browse/WFLY-6903
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1, 11.0.0.Beta1
>
>
> To reproduce run e.g.
> {noformat}
> /subsystem=undertow/servlet-container=default/setting=session-cookie:add(http-only=true)
> {noformat}
> yields NPE when registering with the proxy
> {noformat}2016-08-01 14:42:20,623 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to apache-server/10.0.0.1:6666, configuration will be reset: MEM: Can't read node
> 2016-08-01 14:42:30,626 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) null: java.lang.NullPointerException
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPRequestFactory.createConfigRequest(DefaultMCMPRequestFactory.java:128)
> at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:89)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:399)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6903) Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6903:
---------------------------------
Summary: Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy (was: Configuring session cookie config except for cookie name yields NPE in mod_cluster)
> Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6903
> URL: https://issues.jboss.org/browse/WFLY-6903
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1, 11.0.0.Beta1
>
>
> To reproduce run e.g.
> {noformat}
> /subsystem=undertow/servlet-container=default/setting=session-cookie:add(http-only=true)
> {noformat}
> yields NPE when registering with the proxy
> {noformat}2016-08-01 14:42:20,623 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to apache-server/10.0.0.1:6666, configuration will be reset: MEM: Can't read node
> 2016-08-01 14:42:30,626 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) null: java.lang.NullPointerException
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPRequestFactory.createConfigRequest(DefaultMCMPRequestFactory.java:128)
> at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:89)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:399)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6903) Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6903:
---------------------------------
Workaround: Workaround Exists
> Configuring session cookie config except for cookie name yields NPE in mod_cluster when registering with the proxy
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6903
> URL: https://issues.jboss.org/browse/WFLY-6903
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1, 11.0.0.Beta1
>
>
> To reproduce run e.g.
> {noformat}
> /subsystem=undertow/servlet-container=default/setting=session-cookie:add(http-only=true)
> {noformat}
> yields NPE when registering with the proxy
> {noformat}2016-08-01 14:42:20,623 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to apache-server/10.0.0.1:6666, configuration will be reset: MEM: Can't read node
> 2016-08-01 14:42:30,626 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) null: java.lang.NullPointerException
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPRequestFactory.createConfigRequest(DefaultMCMPRequestFactory.java:128)
> at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:89)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:399)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months