[JBoss JIRA] (JGRP-2343) Change in IPv4 versus IPv6 picking algorithm
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2343?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2343 at 5/8/19 3:49 AM:
--------------------------------------------------------
This is the new algorithm:
h4. Only IPv4 stack is available
* IPv4 addresses are created by default (e.g. by {{InetAddress.getByName()}}, or {{site_local}})
* When an IPv6 address is defined in a configuration, an exception is thrown and the stack will not start
h4. Only IPv6 stack is available
* IPv6 addresses are created by default
* When an IPv4 address is created, convert it to an IPv6-mapped address (default behavior)
h4. Both IPv4 and IPv6 stacks are available (dual stack)
* If {{java.net.preferIPv4Stack=true}}:
** Assign IPv4 addresses by default
** When an IPv6 address is encountered, throw an exception and don't start the stack
* If {{java.net.preferIPv6Addresses=true}}:
** Assign IPv6 addresses by default
** When an IPv4 address is encountered, convert it to an IPv6-mapped address (default behavior)
* Both {{java.net.preferIPv4Stack}} and {{java.net.preferIPv6Addresses}} are set, or none are set
** What's the JDK's preference? (check!) Try to implement the same preference!
** If we have a single IPv6 address (dotted-decimal or symbolic name resolved to IPv6) in the configuration -> Assign IPv6 addresses
** Otherwise -> use IPv4 addresses
For dual stacks (both IPv4 and IPv6 stack is available in the JDK), these changes allow JGroups to run different configurations in the same JVM, e.g. one channel joining an IPv4 cluster, and another one joining an IPv6 cluster.
was (Author: belaban):
This is the new algorithm:
h4. Only IPv4 is available
* IPv4 addresses are created by default (e.g. by {{InetAddress.getByName()}}, or {{site_local}})
* When an IPv6 address is defined in a configuration, an exception is thrown and the stack will not start
h4. Only IPv6 is available
* IPv6 addresses are created by default
* When an IPv4 address is created, convert it to an IPv6-mapped address (default behavior)
h4. Both IPv4 and IPv6 stacks are available (dual stack)
* If {{java.net.preferIPv4Stack=true}}:
** Assign IPv4 addresses by default
** When an IPv6 address is encountered, throw an exception and don't start the stack
* If {{java.net.preferIPv6Addresses=true}}:
** Assign IPv6 addresses by default
** When an IPv4 address is encountered, convert it to an IPv6-mapped address (default behavior)
* Both {{java.net.preferIPv4Stack}} and {{java.net.preferIPv6Addresses}} are set, or none are set
** What's the JDK's preference? (check!) Try to implement the same preference!
** If we have a single IPv6 address (dotted-decimal or symbolic name resolved to IPv6) in the configuration -> Assign IPv6 addresses
** Otherwise -> use IPv4 addresses
> Change in IPv4 versus IPv6 picking algorithm
> --------------------------------------------
>
> Key: JGRP-2343
> URL: https://issues.jboss.org/browse/JGRP-2343
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> When https://issues.jboss.org/browse/JGRP-2305 was implemented, IPv4 was favored unless {{java.net.preferIPv6Addresses}} was set.
> However, this makes the following case fail: no {{java.net.preferXXX}} option is set and the configuration contains one or more IPv6 addresses, e.g. {{UDP bind_addr="::1"}}.
> This will fail, as the new algorithm sets the stack type as IPv4 (it works when {{java.net.preferIPv6Addresses}} is set).
> Change:
> * Look at all IP addresses in a configuration
> * If all addresses are IPv6 and the stack type is IPv4 (and IPv6 is available) -> switch to IPv6 as stack type
> * If all addresses are IPv4 and the stack type is IPv6 (and IPv4 is available) -> switch to IPv4 stack type
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (JGRP-2343) Change in IPv4 versus IPv6 picking algorithm
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2343?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2343:
--------------------------------
This is the new algorithm:
h4. Only IPv4 is available
* IPv4 addresses are created by default (e.g. by {{InetAddress.getByName()}}, or {{site_local}})
* When an IPv6 address is defined in a configuration, an exception is thrown and the stack will not start
h4. Only IPv6 is available
* IPv6 addresses are created by default
* When an IPv4 address is created, convert it to an IPv6-mapped address (default behavior)
h4. Both IPv4 and IPv6 stacks are available (dual stack)
* If {{java.net.preferIPv4Stack=true}}:
** Assign IPv4 addresses by default
** When an IPv6 address is encountered, throw an exception and don't start the stack
* If {{java.net.preferIPv6Addresses=true}}:
** Assign IPv6 addresses by default
** When an IPv4 address is encountered, convert it to an IPv6-mapped address (default behavior)
* Both {{java.net.preferIPv4Stack}} and {{java.net.preferIPv6Addresses}} are set, or none are set
** What's the JDK's preference? (check!) Try to implement the same preference!
** If we have a single IPv6 address (dotted-decimal or symbolic name resolved to IPv6) in the configuration -> Assign IPv6 addresses
** Otherwise -> use IPv4 addresses
> Change in IPv4 versus IPv6 picking algorithm
> --------------------------------------------
>
> Key: JGRP-2343
> URL: https://issues.jboss.org/browse/JGRP-2343
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> When https://issues.jboss.org/browse/JGRP-2305 was implemented, IPv4 was favored unless {{java.net.preferIPv6Addresses}} was set.
> However, this makes the following case fail: no {{java.net.preferXXX}} option is set and the configuration contains one or more IPv6 addresses, e.g. {{UDP bind_addr="::1"}}.
> This will fail, as the new algorithm sets the stack type as IPv4 (it works when {{java.net.preferIPv6Addresses}} is set).
> Change:
> * Look at all IP addresses in a configuration
> * If all addresses are IPv6 and the stack type is IPv4 (and IPv6 is available) -> switch to IPv6 as stack type
> * If all addresses are IPv4 and the stack type is IPv6 (and IPv4 is available) -> switch to IPv4 stack type
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12054) Intermittent failures in WebsocketApplicationScopedTestCase
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12054:
---------------------------------------
Summary: Intermittent failures in WebsocketApplicationScopedTestCase
Key: WFLY-12054
URL: https://issues.jboss.org/browse/WFLY-12054
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Test Suite
Reporter: Brian Stansberry
Assignee: Marek Marusic
https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
Problem is this:
{code}
try (Session session = ContainerProvider.getWebSocketContainer().connectToServer(Client.class, uriUser1)) {
//Wait until the client is initialized e.q. the OnOpen is executed
Thread.sleep(10);
Assert.assertTrue(queues.size() > 0);
{code}
That kind of pattern of a short sleep followed by an assert is not reliable.
This should loop checking periodically and only fail after an appropriate amount of time has passed. Unless that amount of time is relevant to what's being tested it should be a long time, 20 secs min, with TimeoutUtil.adjust used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3986) [DMN Editor] Unable to Execute model with imported nodes
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-3986?page=com.atlassian.jira.plugi... ]
Guilherme Gomes edited comment on DROOLS-3986 at 5/7/19 6:48 PM:
-----------------------------------------------------------------
I've tried to reproduce, and I got this response:
{code:json}
{
"type" : "SUCCESS",
"msg" : "OK from container 'dmn.imports.0.2'",
"result" : {
"dmn-evaluation-result" : {
"messages" : [ {
"dmn-message-severity" : "ERROR",
"message" : "Required dependency 'Cars Per Hour' not found on node 'Traffic'",
"message-type" : "REQ_NOT_FOUND",
"source-id" : "_6BA74389-CBF7-4D6A-99B1-9F494DCC323A"
} ],
"model-namespace" : "https://github.com/kiegroup/drools/kie-dmn/_547C193C-0B52-45F5-877E-F74A7...",
"model-name" : "routes",
"decision-name" : "Traffic.Traffic",
"dmn-context" : {
"Traffic" : { },
"cars per hour" : 10
},
"decision-results" : {
"_AE1DED99-8216-4543-8092-56F8EBDA2869" : {
"messages" : [ ],
"decision-id" : "_AE1DED99-8216-4543-8092-56F8EBDA2869",
"decision-name" : "Traffic",
"result" : null,
"status" : "NOT_EVALUATED"
},
"https://github.com/kiegroup/drools/kie-dmn/_1876D3A2-0972-4AE8-AF59-A56AD..." : {
"messages" : [ {
"dmn-message-severity" : "ERROR",
"message" : "Required dependency 'Cars Per Hour' not found on node 'Traffic'",
"message-type" : "REQ_NOT_FOUND",
"source-id" : "_6BA74389-CBF7-4D6A-99B1-9F494DCC323A"
} ],
"decision-id" : "https://github.com/kiegroup/drools/kie-dmn/_1876D3A2-0972-4AE8-AF59-A56AD...",
"decision-name" : "Traffic.Traffic",
"result" : null,
"status" : "SKIPPED"
}
}
}
}
}
{code}
It do seems like a problem, but I think it's addressed by the https://issues.jboss.org/browse/DROOLS-3985.
was (Author: karreiro):
I've tried to reproduce, and I got this message:
{code:json}
{
"type" : "SUCCESS",
"msg" : "OK from container 'dmn.imports.0.2'",
"result" : {
"dmn-evaluation-result" : {
"messages" : [ {
"dmn-message-severity" : "ERROR",
"message" : "Required dependency 'Cars Per Hour' not found on node 'Traffic'",
"message-type" : "REQ_NOT_FOUND",
"source-id" : "_6BA74389-CBF7-4D6A-99B1-9F494DCC323A"
} ],
"model-namespace" : "https://github.com/kiegroup/drools/kie-dmn/_547C193C-0B52-45F5-877E-F74A7...",
"model-name" : "routes",
"decision-name" : "Traffic.Traffic",
"dmn-context" : {
"Traffic" : { },
"cars per hour" : 10
},
"decision-results" : {
"_AE1DED99-8216-4543-8092-56F8EBDA2869" : {
"messages" : [ ],
"decision-id" : "_AE1DED99-8216-4543-8092-56F8EBDA2869",
"decision-name" : "Traffic",
"result" : null,
"status" : "NOT_EVALUATED"
},
"https://github.com/kiegroup/drools/kie-dmn/_1876D3A2-0972-4AE8-AF59-A56AD..." : {
"messages" : [ {
"dmn-message-severity" : "ERROR",
"message" : "Required dependency 'Cars Per Hour' not found on node 'Traffic'",
"message-type" : "REQ_NOT_FOUND",
"source-id" : "_6BA74389-CBF7-4D6A-99B1-9F494DCC323A"
} ],
"decision-id" : "https://github.com/kiegroup/drools/kie-dmn/_1876D3A2-0972-4AE8-AF59-A56AD...",
"decision-name" : "Traffic.Traffic",
"result" : null,
"status" : "SKIPPED"
}
}
}
}
}
{code}
> [DMN Editor] Unable to Execute model with imported nodes
> --------------------------------------------------------
>
> Key: DROOLS-3986
> URL: https://issues.jboss.org/browse/DROOLS-3986
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: MySpace_dmn.imports (1).zip, error.log
>
>
> This Iss was spotted during review of [PR|https://github.com/kiegroup/kie-wb-common/pull/2620] for DROOLS-3829 and DROOLS-3934.
> User is not able to execute model with imported nodes.
> h3. Steps To Reproduce
> # Deploy the attached project to kie server
> # Try to execute the model as:
> {code:sh}
> curl -u testadmin:'admin1234;' -H "accept: application/json" -H "content-type: application/json" -X POST "http://localhost:8080/kie-server/services/rest/server/containers/dmn.impo..." -d "{ \"model-namespace\" : \"https://github.com/kiegroup/drools/kie-dmn/_547C193C-0B52-45F5-877E-F74A7...", \"model-name\" : \"routes\", \"decision-name\" : [\"Traffic.Traffic\" ], \"decision-id\" : [ ], \"dmn-context\" : {\"cars per hour\" : 10}}"
> {code}
> # You will get result:
> {code:json}
> {
> "type" : "FAILURE",
> "msg" : "Error from container 'dmn.imports'Unable to locate DMN Model to evaluate",
> "result" : null
> }{code}
> # Error appears in server log: [^error.log]
> h3. Actual result
> There is response error message and error in server log
> h3. Expected result
> Model is executed
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3986) [DMN Editor] Unable to Execute model with imported nodes
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-3986?page=com.atlassian.jira.plugi... ]
Guilherme Gomes commented on DROOLS-3986:
-----------------------------------------
I've tried to reproduce, and I got this message:
{code:json}
{
"type" : "SUCCESS",
"msg" : "OK from container 'dmn.imports.0.2'",
"result" : {
"dmn-evaluation-result" : {
"messages" : [ {
"dmn-message-severity" : "ERROR",
"message" : "Required dependency 'Cars Per Hour' not found on node 'Traffic'",
"message-type" : "REQ_NOT_FOUND",
"source-id" : "_6BA74389-CBF7-4D6A-99B1-9F494DCC323A"
} ],
"model-namespace" : "https://github.com/kiegroup/drools/kie-dmn/_547C193C-0B52-45F5-877E-F74A7...",
"model-name" : "routes",
"decision-name" : "Traffic.Traffic",
"dmn-context" : {
"Traffic" : { },
"cars per hour" : 10
},
"decision-results" : {
"_AE1DED99-8216-4543-8092-56F8EBDA2869" : {
"messages" : [ ],
"decision-id" : "_AE1DED99-8216-4543-8092-56F8EBDA2869",
"decision-name" : "Traffic",
"result" : null,
"status" : "NOT_EVALUATED"
},
"https://github.com/kiegroup/drools/kie-dmn/_1876D3A2-0972-4AE8-AF59-A56AD..." : {
"messages" : [ {
"dmn-message-severity" : "ERROR",
"message" : "Required dependency 'Cars Per Hour' not found on node 'Traffic'",
"message-type" : "REQ_NOT_FOUND",
"source-id" : "_6BA74389-CBF7-4D6A-99B1-9F494DCC323A"
} ],
"decision-id" : "https://github.com/kiegroup/drools/kie-dmn/_1876D3A2-0972-4AE8-AF59-A56AD...",
"decision-name" : "Traffic.Traffic",
"result" : null,
"status" : "SKIPPED"
}
}
}
}
}
{code}
> [DMN Editor] Unable to Execute model with imported nodes
> --------------------------------------------------------
>
> Key: DROOLS-3986
> URL: https://issues.jboss.org/browse/DROOLS-3986
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: MySpace_dmn.imports (1).zip, error.log
>
>
> This Iss was spotted during review of [PR|https://github.com/kiegroup/kie-wb-common/pull/2620] for DROOLS-3829 and DROOLS-3934.
> User is not able to execute model with imported nodes.
> h3. Steps To Reproduce
> # Deploy the attached project to kie server
> # Try to execute the model as:
> {code:sh}
> curl -u testadmin:'admin1234;' -H "accept: application/json" -H "content-type: application/json" -X POST "http://localhost:8080/kie-server/services/rest/server/containers/dmn.impo..." -d "{ \"model-namespace\" : \"https://github.com/kiegroup/drools/kie-dmn/_547C193C-0B52-45F5-877E-F74A7...", \"model-name\" : \"routes\", \"decision-name\" : [\"Traffic.Traffic\" ], \"decision-id\" : [ ], \"dmn-context\" : {\"cars per hour\" : 10}}"
> {code}
> # You will get result:
> {code:json}
> {
> "type" : "FAILURE",
> "msg" : "Error from container 'dmn.imports'Unable to locate DMN Model to evaluate",
> "result" : null
> }{code}
> # Error appears in server log: [^error.log]
> h3. Actual result
> There is response error message and error in server log
> h3. Expected result
> Model is executed
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12050) WildFly management console fails to load deployments if war fails to deploy
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12050?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-12050:
---------------------------------------
Component/s: Web (Undertow)
(was: Web Console)
Assignee: Flavia Rainone (was: Harald Pehl)
Changing the component on this as this isn't really a client side console problem.
https://github.com/wildfly/wildfly/pull/12263 is the likely fix.
> WildFly management console fails to load deployments if war fails to deploy
> ---------------------------------------------------------------------------
>
> Key: WFLY-12050
> URL: https://issues.jboss.org/browse/WFLY-12050
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 16.0.0.Final
> Reporter: Philippe Julien
> Assignee: Flavia Rainone
> Priority: Major
> Attachments: Screen Shot 2019-05-06 at 10.37.03 AM.png
>
>
> When a .war that has servlets declared using @WebServlet fails to deploy, the console cannot list any deployments.
> Here is the exception that is logged by WildFly:
> {noformat}
> 09:52:08.629 [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "test-war.war"),
> ("subsystem" => "undertow"),
> ("servlet" => "com.test.TestServlet")
> ]): java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50)
> at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler$1.execute(DeploymentServletDefinition.java:175)
> 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.OperationContextImpl.executeOperation(OperationContextImpl.java:1412)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 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:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {noformat}
> I have pushed a small reproducer .war application here: https://github.com/philippejulien/test-war
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4462) Restart level calculation in SimpleResourceDefinition.Parameters is ineffective.
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4462:
----------------------------------------
Summary: Restart level calculation in SimpleResourceDefinition.Parameters is ineffective.
Key: WFCORE-4462
URL: https://issues.jboss.org/browse/WFCORE-4462
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 9.0.0.Beta4, 8.0.0.Final
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
Parameters attempts to set a restart level for add or remove based on the type of the handler for the op:
{code}
public Parameters setAddHandler(OperationStepHandler addHandler) {
this.addHandler = addHandler;
if (this.addRestartLevel == null) {
this.addRestartLevel = restartLevelForAdd(addHandler);
}
return this;
}
{code}
The problem is restartLevelForAdd(addHandler) doesn't get called because this.addRestartLevel and this.removeRestartLevel are initialized to non-null values.
The effect of this is SimpleResourceDefinition impls that moved from passing multiple params to the constructor to instead passing a Parameters object have had the restart-level description of their add and remove ops changed.
This is tricky because fixing this means some things may get changed back.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12019) Cannot remove a undertow server resource at one time
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12019?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFLY-12019 at 5/7/19 3:32 PM:
-----------------------------------------------------------------
[~jmesnil] FYI ^^^.
[~spyrkob] That's a bug. In this particular case maybe a good one, as the old setting didn't work properly. But in general that kind of change shouldn't happen.
[~kabirkhan] Does the management API diff thing compare operation definitions, or does it just do resources/attributes?
The problem is SimpleResourceDefinition.Parameters.setRemoveHandler() has similar logic to the old SimpleResourceDefinition constructor (figure out the restart level from the handler type), but it doesn't work because it only executes if the restartLevel is null. And it's not null; it's initialized to RESTART_ALL_SERVICES.
https://issues.jboss.org/browse/WFCORE-4462
was (Author: brian.stansberry):
[~jmesnil] FYI ^^^.
[~spyrkob] That's a bug. In this particular case maybe a good one, as the old setting didn't work properly. But in general that kind of change shouldn't happen.
[~kabirkhan] Does the management API diff thing compare operation definitions, or does it just do resources/attributes?
The problem is SimpleResourceDefinition.Parameters.setRemoveHandler() has similar logic to the old SimpleResourceDefinition constructor (figure out the restart level from the handler type), but it doesn't work because it only executes if the restartLevel is null. And it's not null; it's initialized to RESTART_ALL_SERVICES.
> Cannot remove a undertow server resource at one time
> ----------------------------------------------------
>
> Key: WFLY-12019
> URL: https://issues.jboss.org/browse/WFLY-12019
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 16.0.0.Final
> Reporter: Bartosz Spyrko
> Assignee: Bartosz Spyrko
> Priority: Major
>
> Cannot remove a server attribute.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.undertow.server.default-server.default-host was depended upon by service jboss.undertow.server.default-server.default-host.filter-ref.x-powered-by-header, service jboss.undertow.server.default-server.default-host.location.
> /, service jboss.undertow.server.default-server.default-host.filter-ref.server-header",
> "rolled-back" => true,
> "response-headers" => undefined
> }
> {noformat}
> However, it can be removed executing same command again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12019) Cannot remove a undertow server resource at one time
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12019?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12019:
-----------------------------------------
[~jmesnil] FYI ^^^.
[~spyrkob] That's a bug. In this particular case maybe a good one, as the old setting didn't work properly. But in general that kind of change shouldn't happen.
[~kabirkhan] Does the management API diff thing compare operation definitions, or does it just do resources/attributes?
The problem is SimpleResourceDefinition.Parameters.setRemoveHandler() has similar logic to the old SimpleResourceDefinition constructor (figure out the restart level from the handler type), but it doesn't work because it only executes if the restartLevel is null. And it's not null; it's initialized to RESTART_ALL_SERVICES.
> Cannot remove a undertow server resource at one time
> ----------------------------------------------------
>
> Key: WFLY-12019
> URL: https://issues.jboss.org/browse/WFLY-12019
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 16.0.0.Final
> Reporter: Bartosz Spyrko
> Assignee: Bartosz Spyrko
> Priority: Major
>
> Cannot remove a server attribute.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.undertow.server.default-server.default-host was depended upon by service jboss.undertow.server.default-server.default-host.filter-ref.x-powered-by-header, service jboss.undertow.server.default-server.default-host.location.
> /, service jboss.undertow.server.default-server.default-host.filter-ref.server-header",
> "rolled-back" => true,
> "response-headers" => undefined
> }
> {noformat}
> However, it can be removed executing same command again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
