[
https://issues.jboss.org/browse/WFCORE-1953?page=com.atlassian.jira.plugi...
]
Brian Stansberry resolved WFCORE-1953.
--------------------------------------
Resolution: Won't Do
I'm rejecting this. See comments in
https://issues.jboss.org/browse/JBEAP-10168.
I oppose supporting allow-resource-service-restart=true in the elytron subsystem.
Restarting a service that is close to the root of the service dependency graph is going to
have a practical effect little different from a reload.
I don't think we should expend energy adding support for it anywhere at all. It's
a power user thing without enough practical benefit to justify the cost to implement and
the fragility that results.
Also, in a cloud world, config changes are made as part of the image build and then the
updated image is rolled out to the pods. Trying to make a reload go away means we are
spending our energy on non-cloud use cases. (And even in bare metal uses cases people are
often unwilling to live update a production server.)
Note that the UnsupportedOperationException has been fixed in a different issue.
Elytron allow-resource-service-restart=true handling
----------------------------------------------------
Key: WFCORE-1953
URL:
https://issues.jboss.org/browse/WFCORE-1953
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha11
Reporter: Martin Choma
Elytron can not handle {{allow-resource-service-restart=true}} header properly on many
places.
For example if I try to update http-authentication-factory with
{{allow-resource-service-restart=true}} header, I get
{code}
[standalone@localhost:9990 /]
/subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory,
value=global){allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed:
java.lang.UnsupportedOperationException",
"rolled-back" => true
}
{code}
And exception in server log
{code:title=server.log}
11:22:20,312 ERROR [org.jboss.as.controller.management-operation]
(management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute")
failed - address: ([
("subsystem" => "elytron"),
("http-authentication-factory" =>
"application-http-authentication")
]): java.lang.UnsupportedOperationException
at
org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:145)
at
org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:126)
at
org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:72)
at
org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at
org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at
org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at
org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
at
org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
at
org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at
org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at
org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at
org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at
org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at
org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at
org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
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)
{code}
Similar behaviour can be seen in:
* {{kerberos-security-factory}}
* {{filesystem-realm}}
* {{constant-principal-decoder}}
On the other hand I don't see this issue in {{security-domain}}
Possible solutions:
* restart services
** possibility of reload big part of server anyway; either management part or application
part
* live updates
** if resource would accept runtime updates resource won't need to reload
** most user friendly, most work
** tracked as own issue JBEAP-6961
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)