[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 commented on WFCORE-3040:
------------------------------------------
This looks like an undertow subsystem bug. As you say, [~ehugonnet], ListenerResourceDefinition uses RuntimeCapability.Builder.addDynamicRequirements -- which is deprecated because it has no meaningful function at this time.
ListenerAdd needs to record its requirement on the appropriate CAPABILITY_SERVER.
I suspect HostDefinition has the same issue.
> 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, 10 months
[JBoss JIRA] (WFLY-9099) EJB run-as identity gets lost if an unsecured ejb in the call stack - not fixed in Elytron
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-9099?page=com.atlassian.jira.plugin.... ]
Farah Juma moved JBEAP-12198 to WFLY-9099:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9099 (was: JBEAP-12198)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Security
(was: EJB)
(was: Security)
Affects Version/s: (was: 7.1.0.ER2)
> EJB run-as identity gets lost if an unsecured ejb in the call stack - not fixed in Elytron
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-9099
> URL: https://issues.jboss.org/browse/WFLY-9099
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Critical
>
> Follow up to JBEAP-11462, because this issue doesn't seem to be resolved in the case where Elytron is used.
> To reproduce, use the same steps as in JBEAP-11462, but instead of creating a {{jmx-console}} security domain, create an {{application-security-domain}} mapping from {{jmx-console}} to {{ApplicationDomain}} Elytron domain.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3056) Model is not validated for write attribute handlers like it is add/remove ones
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3056?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3056:
----------------------------------------
Assignee: Ingo Weiss (was: Brian Stansberry)
[~iweiss] Please see my comment on WFCORE-3055. Perhaps it's more applicable here than there or is applicable to both.
> Model is not validated for write attribute handlers like it is add/remove ones
> ------------------------------------------------------------------------------
>
> Key: WFCORE-3056
> URL: https://issues.jboss.org/browse/WFCORE-3056
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta28
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
>
> When creating a new subsystem attribute and using .setValidator(new StringAllowedValuesValidator()) as in the below example:
> {code:java}
> public static final SimpleAttributeDefinition CACHE_TYPE = new SimpleAttributeDefinitionBuilder(Constants.CACHE_TYPE, ModelType.STRING, true)
> .setAllowExpression(true)
> .setValidator(new StringAllowedValuesValidator("default", INFINISPAN_CACHE_TYPE))
> .build();
> {code}
> The model is not validated during runtime, leading to WildFly not being able to boot after a reload due to an invalid model.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3055) AD#setAllowedValues() does not set validator, leading to incorrect values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3055?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3055:
----------------------------------------
Assignee: Ingo Weiss (was: Brian Stansberry)
[~iweiss] I'm assigning this back to you because I believe the issue here is SecurityDomainResoureDefinition is not passing the AD into the SecurityDomainReloadWriteHandler constructor. Therefore the AD is not available to the handler and its validation code is skipped (see the AbstractWriteAttributeHandler.execute impl).
If I'm correct please close this one.
> AD#setAllowedValues() does not set validator, leading to incorrect values
> -------------------------------------------------------------------------
>
> Key: WFCORE-3055
> URL: https://issues.jboss.org/browse/WFCORE-3055
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta28
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
>
> When creating a new subsystem attribute and using {{.setAllowedValues()}} as in the below example:
> {code:java}
> public static final SimpleAttributeDefinition CACHE_TYPE = new SimpleAttributeDefinitionBuilder(Constants.CACHE_TYPE, ModelType.STRING, true)
> .setAllowExpression(true)
> .setAllowedValues("default", "infinispan")
> .build();
> {code}
> The model is not validated, leading to invalid values on the model.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3073) Handle TERM cleanly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-9062 to WFCORE-3073:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3073 (was: WFLY-9062)
Component/s: Server
(was: Server)
> Handle TERM cleanly
> -------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Server
> Reporter: Ben Parees
> Assignee: Jason Greene
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3073) Handle TERM cleanly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3073:
------------------------------------------
I moved this to WFCORE as that's where the handling of signals is.
> Handle TERM cleanly
> -------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Server
> Reporter: Ben Parees
> Assignee: Jason Greene
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3059) suggest-capabilities returns suffix when the capability contains a dot
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3059?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3059:
-------------------------------------
Component/s: Domain Management
(was: Security)
Description:
Given the following operation to add credential-store.
{code}
/profile=full/subsystem=elytron/credential-store=store.foo:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
/profile=full/subsystem=elytron/credential-store=store2:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
{code}
There is a problem related to the naming used in "store.foo", the suggest-capabilities operation will return only the suffix "foo" instead of the resource name "store.foo"
{code}
/host=master/core-service=capability-registry:suggest-capabilities(name=org.wildfly.security.credential-store,dependent-address=[("profile" => "full"),("subsystem" => "elytron"),("credential-store" => "*")])
{
"outcome" => "success",
"result" => [
"store2",
"foo"
]
}
{code}
This presents a problem for capability-reference, as the auto complete on CLI (using tab) and Web Console returns "foo" and "store2" as value.
was:
Given the following operation to add credential-store.
{code}
/profile=full/subsystem=elytron/credential-store=store.foo:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
/profile=full/subsystem=elytron/credential-store=store2:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
{code}
There is a problem related to the naming used in "store.foo", the suggest-capabilities operation will return only the suffix "foo" instead of the resource name "store.foo"
{code}
/host=master/core-service=capability-registry:suggest-capabilities(name=org.wildfly.security.credential-store,dependent-address=[("profile" => "full"),("subsystem" => "elytron"),("credential-store" => "*")])
{
"outcome" => "success",
"result" => [
"store2",
"foo"
]
}
{code}
This presents a problem for capability-reference, as the auto complete on CLI (using tab) and Web Console returns "foo" and "store2" as value.
[~dlofthouse] It sounds like a general issue.
> suggest-capabilities returns suffix when the capability contains a dot
> ----------------------------------------------------------------------
>
> Key: WFCORE-3059
> URL: https://issues.jboss.org/browse/WFCORE-3059
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
>
> Given the following operation to add credential-store.
> {code}
> /profile=full/subsystem=elytron/credential-store=store.foo:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
> /profile=full/subsystem=elytron/credential-store=store2:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
> {code}
> There is a problem related to the naming used in "store.foo", the suggest-capabilities operation will return only the suffix "foo" instead of the resource name "store.foo"
> {code}
> /host=master/core-service=capability-registry:suggest-capabilities(name=org.wildfly.security.credential-store,dependent-address=[("profile" => "full"),("subsystem" => "elytron"),("credential-store" => "*")])
> {
> "outcome" => "success",
> "result" => [
> "store2",
> "foo"
> ]
> }
> {code}
> This presents a problem for capability-reference, as the auto complete on CLI (using tab) and Web Console returns "foo" and "store2" as value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months