[JBoss JIRA] (WFCORE-2680) http-interface.http-upgrade should not be marked as "restart-required" => "no-services"
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2680?page=com.atlassian.jira.plugi... ]
Ken Wills closed WFCORE-2680.
-----------------------------
Resolution: Duplicate Issue
Duplicates https://issues.jboss.org/browse/WFCORE-2685
> http-interface.http-upgrade should not be marked as "restart-required" => "no-services"
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-2680
> URL: https://issues.jboss.org/browse/WFCORE-2680
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Martin Choma
> Assignee: Brian Stansberry
>
> Although {{http-upgrade}} attribute is marked as {{"restart-required" => "no-services"}} in model, when I try change it, server gets into reload required state, anyway.
> {code}
> [standalone@localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-sasl-authentication)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> This issue foolows-up JBEAP-9137, where all other {{http-interface}} where marked as {{"restart-required" => "all-services"}}. So seems to me {{http-upgrade}} was ommited just by mistake.
> {code}
> "http-upgrade" => {
> "type" => OBJECT,
> "description" => "HTTP Upgrade specific configuration",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "value-type" => {
> "enabled" => {
> "type" => BOOLEAN,
> "description" => "Flag that indicates HTTP Upgrade is enabled, which allows HTTP requests to be upgraded to native remoting connections",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => false
> },
> "sasl-authentication-factory" => {
> "type" => STRING,
> "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8600) Management socket binding in Undertow mod_cluster filter is missing capability reference
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8600?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-10440 to WFLY-8600:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8600 (was: JBEAP-10440)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: mod_cluster
Web (Undertow)
(was: mod_cluster)
(was: Web (Undertow))
Target Release: (was: 7.1.0.GA)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR9)
> Management socket binding in Undertow mod_cluster filter is missing capability reference
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-8600
> URL: https://issues.jboss.org/browse/WFLY-8600
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Values for 'Management socket binding' are not suggested when editing mod_cluster filter in Web Console because of missing support in Undertow subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1092) CS tool, There is success message when we try to list aliases from non-existent storage file.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1092?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1092:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> CS tool, There is success message when we try to list aliases from non-existent storage file.
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-1092
> URL: https://issues.jboss.org/browse/ELY-1092
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> When we try to list aliases in non-existent credential store storage file then we get success message.
> There is expected error message.
> *How to reproduce:*
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --aliases secret_alias --password pass123 --uri "cr-store:///tmp/non-existent-file.jceks?modifiable=true;create=true;keyStoreType=JCEKS"
> Credential store contains following aliases:
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1093) CS tool, When we try to find out if alias exists in non-existent credential store storage file then we get success message.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1093?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1093:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> CS tool, When we try to find out if alias exists in non-existent credential store storage file then we get success message.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1093
> URL: https://issues.jboss.org/browse/ELY-1093
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> When we try to find out if alias exists in non-existent credential store storage file then we get success message.
> There is expected error message rather then success with information that Alias does not exist.
> *How to reproduce:*
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --exists secret_alias --password pass1234 --uri "cr-store:///tmp/non-existent-file.jceks?modifiable=true;create=true;keyStoreType=JCEKS"
> Alias "secret_alias" does not exist
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (LOGMGR-152) Add server and process name & id fields to log record
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-152?page=com.atlassian.jira.plugin... ]
David Lloyd edited comment on LOGMGR-152 at 4/19/17 10:57 AM:
--------------------------------------------------------------
I've created WFCOM-14 to specify that some of this behavior should come from wildfly-common.
was (Author: dmlloyd):
I've created WFCOM-4 to specify that some of this behavior should come from wildfly-common.
> Add server and process name & id fields to log record
> -----------------------------------------------------
>
> Key: LOGMGR-152
> URL: https://issues.jboss.org/browse/LOGMGR-152
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Reporter: David Lloyd
> Priority: Minor
>
> In order to support aggregation of log records with some awareness of origin, we would need server name and process name and id arguments on ExtLogRecord.
> The server name is a string field which contains the host name of the log record producer. The default value for this field would be {{org.wildfly.common.net.HostName#getHostName()}}. If the field is not present on deserialize, "<unknown>" could be used.
> The process name is a string field which contains the name of the process. The default value for this field could be extracted from the first part of the {{sun.java.command}} system property. It would be configurable via system property, e.g. {{jboss.logmanager.process.name}} or something. If the field is not present on deserialize, "<unknown>" could be used.
> The process ID field is a long field that contains the ID of the process. The value of this field should be set from ProcessHandle.current().pid() on Java 9. On Java 8 and earlier, you can use {{ManagementFactory.getRuntimeMXBean().getName()}} and parse the numeric data up to the {{@}} symbol. If the data does not parse, or the field is not present on deserialize, -1L should be used to indicate an unknown PID.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (LOGMGR-152) Add server and process name & id fields to log record
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-152?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGMGR-152:
------------------------------------
I've created WFCOM-4 to specify that some of this behavior should come from wildfly-common.
> Add server and process name & id fields to log record
> -----------------------------------------------------
>
> Key: LOGMGR-152
> URL: https://issues.jboss.org/browse/LOGMGR-152
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Reporter: David Lloyd
> Priority: Minor
>
> In order to support aggregation of log records with some awareness of origin, we would need server name and process name and id arguments on ExtLogRecord.
> The server name is a string field which contains the host name of the log record producer. The default value for this field would be {{org.wildfly.common.net.HostName#getHostName()}}. If the field is not present on deserialize, "<unknown>" could be used.
> The process name is a string field which contains the name of the process. The default value for this field could be extracted from the first part of the {{sun.java.command}} system property. It would be configurable via system property, e.g. {{jboss.logmanager.process.name}} or something. If the field is not present on deserialize, "<unknown>" could be used.
> The process ID field is a long field that contains the ID of the process. The value of this field should be set from ProcessHandle.current().pid() on Java 9. On Java 8 and earlier, you can use {{ManagementFactory.getRuntimeMXBean().getName()}} and parse the numeric data up to the {{@}} symbol. If the data does not parse, or the field is not present on deserialize, -1L should be used to indicate an unknown PID.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2690) Undertow CLI completion for /subsystem=undertow[default-virtual-host] offers also server name
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2690?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved JBEAP-10436 to WFCORE-2690:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2690 (was: JBEAP-10436)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR16)
> Undertow CLI completion for /subsystem=undertow[default-virtual-host] offers also server name
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-2690
> URL: https://issues.jboss.org/browse/WFCORE-2690
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Minor
>
> CLI autocompletion in Undertow subsystem for attribute {{/subsystem=undertow\[default-virtual-host\]}} does not work correctly. When you try to tab-complete with following command and default configuration in use:
> {code}
> /subsystem=undertow:write-attribute(name=default-virtual-host,value=
> {code}
> CLI will offer you this:
> {code}
> /subsystem=undertow:write-attribute(name=default-virtual-host,value=default-server.default-host
> {code}
> which is not correct as accepted attribute value is just virtual host name, in this case that means '{{default-host}}'.
> Expected behavior is that CLI will offer you just names of virtual hosts with tab-completion.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar edited comment on WFLY-7987 at 4/19/17 10:19 AM:
-------------------------------------------------------------
[~ggam] could you check if latest nightly builds behave any better when it comes to undertow subsystem?
was (Author: ctomc):
[~ggam] you could check if latest nightly builds behave any better when it comes to undertow subsystem?
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Tomaz Cerar
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-7987:
-----------------------------------
[~ggam] you could check if latest nightly builds behave any better when it comes to undertow subsystem?
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Tomaz Cerar
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (LOGMGR-152) Add server and process name & id fields to log record
by David Lloyd (JIRA)
David Lloyd created LOGMGR-152:
----------------------------------
Summary: Add server and process name & id fields to log record
Key: LOGMGR-152
URL: https://issues.jboss.org/browse/LOGMGR-152
Project: JBoss Log Manager
Issue Type: Enhancement
Components: core
Reporter: David Lloyd
Priority: Minor
In order to support aggregation of log records with some awareness of origin, we would need server name and process name and id arguments on ExtLogRecord.
The server name is a string field which contains the host name of the log record producer. The default value for this field would be {{org.wildfly.common.net.HostName#getHostName()}}. If the field is not present on deserialize, "<unknown>" could be used.
The process name is a string field which contains the name of the process. The default value for this field could be extracted from the first part of the {{sun.java.command}} system property. It would be configurable via system property, e.g. {{jboss.logmanager.process.name}} or something. If the field is not present on deserialize, "<unknown>" could be used.
The process ID field is a long field that contains the ID of the process. The value of this field should be set from ProcessHandle.current().pid() on Java 9. On Java 8 and earlier, you can use {{ManagementFactory.getRuntimeMXBean().getName()}} and parse the numeric data up to the {{@}} symbol. If the data does not parse, or the field is not present on deserialize, -1L should be used to indicate an unknown PID.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years