July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9116) Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9116?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9116: ----------------------------------- Summary: Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements (was: Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements, record missing requirements) > Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-9116 > URL: https://issues.jboss.org/browse/WFLY-9116 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued. > What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel. > But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this. > Reproducer, starting with a near empty config a la standalone-minimalistic.xml: > {code:java} > /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow") > /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io") > batch > /subsystem=undertow:add > /subsystem=undertow/servlet-container=default:add > /subsystem=undertow/server=default-server:add > /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"]) > /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http") > /subsystem=undertow/buffer-cache=default:add > /subsystem=undertow/configuration=handler:add > /subsystem=undertow/configuration=filter:add > /subsystem=io:add > /subsystem=io/buffer-pool=default:add > /subsystem=io/worker=default:add > /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}") > run-batch > {code} > The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9116) Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements, record missing requirements

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9116?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9116: ----------------------------------- Summary: Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements, record missing requirements (was: Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements) > Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements, record missing requirements > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9116 > URL: https://issues.jboss.org/browse/WFLY-9116 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued. > What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel. > But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this. > Reproducer, starting with a near empty config a la standalone-minimalistic.xml: > {code:java} > /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow") > /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io") > batch > /subsystem=undertow:add > /subsystem=undertow/servlet-container=default:add > /subsystem=undertow/server=default-server:add > /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"]) > /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http") > /subsystem=undertow/buffer-cache=default:add > /subsystem=undertow/configuration=handler:add > /subsystem=undertow/configuration=filter:add > /subsystem=io:add > /subsystem=io/buffer-pool=default:add > /subsystem=io/worker=default:add > /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}") > run-batch > {code} > The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9107) Block non-SSL IIOP port when SSL transport is required

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-9107?page=com.atlassian.jira.plugin.... ] Tomasz Adamski reassigned WFLY-9107: ------------------------------------ Assignee: Tomasz Adamski (was: Jason Greene) > Block non-SSL IIOP port when SSL transport is required > ------------------------------------------------------ > > Key: WFLY-9107 > URL: https://issues.jboss.org/browse/WFLY-9107 > Project: WildFly > Issue Type: Enhancement > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3040) StepCapabilityStatus should take dynamic capability dependencies into account

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3040?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-3040. -------------------------------------- Resolution: Rejected I'm closing this one as there's no kernel bug here. WFLY-9116 is to track the subsystem problem that leads to this behavior. > StepCapabilityStatus should take dynamic capability dependencies into account > ----------------------------------------------------------------------------- > > Key: WFCORE-3040 > URL: https://issues.jboss.org/browse/WFCORE-3040 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta28 > Reporter: ehsavoie Hugonnet > Assignee: Brian Stansberry > > Currently at stage RUNTIME we check the stepCapabilityStatus before executing the OSH associated with a capability. But this check doesn't take into account the state of the capability dependencies. > For example if we add the undertow subsystem from scratch : the server service is not added because its capability is RELOAD_REQUIRED but when adding the listener the stepCapabilityStatus is NORMAL while it depends on a service that is in RELOAD_REQUIRED so is potentially not there (which is the case) thus the RUNTIME OSH will fail instead of being skipped. > Reproducer: > {code:java} > /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow") > /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io") > batch > /subsystem=undertow:add > /subsystem=undertow/servlet-container=default:add > /subsystem=undertow/server=default-server:add > /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"]) > /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http") > /subsystem=undertow/buffer-cache=default:add > /subsystem=undertow/configuration=handler:add > /subsystem=undertow/configuration=filter:add > /subsystem=io:add > /subsystem=io/buffer-pool=default:add > /subsystem=io/worker=default:add > /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}") > run-batch > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9116) Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9116: -------------------------------------- Summary: Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements Key: WFLY-9116 URL: https://issues.jboss.org/browse/WFLY-9116 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Brian Stansberry Assignee: Brian Stansberry RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued. What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel. But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this. Reproducer, starting with a near empty config a la standalone-minimalistic.xml: {code:java} /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow") /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io") batch /subsystem=undertow:add /subsystem=undertow/servlet-container=default:add /subsystem=undertow/server=default-server:add /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"]) /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http") /subsystem=undertow/buffer-cache=default:add /subsystem=undertow/configuration=handler:add /subsystem=undertow/configuration=filter:add /subsystem=io:add /subsystem=io/buffer-pool=default:add /subsystem=io/worker=default:add /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}") run-batch {code} The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1669) NullPointerException in FlatQueryResults.<init> ("left join" query)

by Russell Morrisey (JIRA)

Russell Morrisey created DROOLS-1669: ---------------------------------------- Summary: NullPointerException in FlatQueryResults.<init> ("left join" query) Key: DROOLS-1669 URL: https://issues.jboss.org/browse/DROOLS-1669 Project: Drools Issue Type: Bug Components: core engine, kie server Affects Versions: 6.5.0.Final Environment: Win7 x64, Tomcat 9, workbench-built DRL, managed KIE Server execution Reporter: Russell Morrisey Assignee: Mario Fusco The following DRL query passes build and validation in the workbench, but fails at runtime in KIE Server: {code:java} query "questionsKnowledge" () $question: Question() $visible: QuestionVisible(question == $question) or not QuestionVisible(question == $question) end {code} The intent is that $visible may or may not be bound, depending on whether QuestionVisible is present. It looks like this causes an error in FlatQueryResults.(init): {code:java} 15:59:30.897 ERROR o.k.s.s.d.DroolsKieContainerCommandServiceImpl - Error calling container 'qna2' java.lang.NullPointerException: null at org.drools.core.QueryResultsRowImpl.getFactHandle(QueryResultsRowImpl.java:99) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.QueryResultsRowImpl.getFactHandle(QueryResultsRowImpl.java:95) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.runtime.rule.impl.FlatQueryResults.<init>(FlatQueryResults.java:116) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.command.runtime.rule.QueryCommand.execute(QueryCommand.java:109) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.command.runtime.rule.QueryCommand.execute(QueryCommand.java:39) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final.jar:6.5.0.Final] at org.kie.server.services.drools.RulesExecutionService.call(RulesExecutionService.java:52) ~[kie-server-services-drools-6.5.0.Final.jar:6.5.0.Final] at org.kie.server.services.drools.DroolsKieContainerCommandServiceImpl.callContainer(DroolsKieContainerCommandServiceImpl.java:69) ~[kie-server-services-drools-6.5.0.Final.jar:6.5.0.Final ] at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:72) [kie-server-rest-drools-6.5.0.Final.jar:6.5.0.Final] {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3082) Upgrade commons-logging-jboss-logmanager from 1.0.0.Final to 1.0.1.Final

by James Perkins (JIRA)

James Perkins created WFCORE-3082: ------------------------------------- Summary: Upgrade commons-logging-jboss-logmanager from 1.0.0.Final to 1.0.1.Final Key: WFCORE-3082 URL: https://issues.jboss.org/browse/WFCORE-3082 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins Upgrade commons-logging-jboss-logmanager from 1.0.0.Final to 1.0.1.Final. Only a single change to make the log implementation serializable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9115) Toggling default singleton election policy fails

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9115?page=com.atlassian.jira.plugin.... ] Radoslav Husar moved JBEAP-12253 to WFLY-9115: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9115 (was: JBEAP-12253) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.ER2) > Toggling default singleton election policy fails > ------------------------------------------------ > > Key: WFLY-9115 > URL: https://issues.jboss.org/browse/WFLY-9115 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > {noformat} > [standalone@localhost:9990 /] /subsystem=singleton/singleton-policy=foo/election-policy=random:add{allow-resource-service-restart=true > {"outcome" => "success"} > [standalone@localhost:9990 /] /subsystem=singleton/singleton-policy=foo/election-policy=simple:add{allow-resource-service-restart=true > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.singleton.policy.election.foo' at location '[ > (\"subsystem\" => \"singleton\"), > (\"singleton-policy\" => \"foo\"), > (\"election-policy\" => \"simple\") > ]' as it is already registered in context 'global' at location(s) '[[ > (\"subsystem\" => \"singleton\"), > (\"singleton-policy\" => \"foo\"), > (\"election-policy\" => \"random\") > ]]'", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1297) Enable error messages from SCRAM server when checking binding data conditions

by Pedro Igor (JIRA)

Pedro Igor created ELY-1297: ------------------------------- Summary: Enable error messages from SCRAM server when checking binding data conditions Key: ELY-1297 URL: https://issues.jboss.org/browse/ELY-1297 Project: WildFly Elytron Issue Type: Bug Components: SASL Affects Versions: 1.1.0.CR2 Reporter: Pedro Igor Assignee: Pedro Igor Fix For: 1.1.0.CR3 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3081) Create test case for Elytron custom-credential-security-factory resource

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3081?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-8835 to WFCORE-3081: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-3081 (was: WFLY-8835) Component/s: Security Test Suite (was: Test Suite) > Create test case for Elytron custom-credential-security-factory resource > ------------------------------------------------------------------------ > > Key: WFCORE-3081 > URL: https://issues.jboss.org/browse/WFCORE-3081 > Project: WildFly Core > Issue Type: Bug > Components: Security, Test Suite > Reporter: Hynek Švábek > Assignee: Hynek Švábek > > Create test case for custom-credential-security-factory resource. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2017