[jboss-jira] [JBoss JIRA] (WFCORE-1953) Elytron allow-resource-service-restart=true handling

[Martin Choma (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541376#comment-13541376 ] 

Martin Choma commented on WFCORE-1953:
--------------------------------------

There is some demand for runtime changes - see https://issues.jboss.org/browse/EAP7-455 But I get that with cloud environment this demand is getting marginal now.

I understand argument about security subsystem resources having impact on big part of server. But I must ask one additional question. How you look at "custom service restarts"? I mean we have key-manager:init() which effectivelly restart service with respect to key-store file content changes (no model attributes changes are taken into account so far). So what do you think about extending this "custom service restart" operation also to model attributes? And not propagating reload event further in dependency tree?

I feel we would start to mess general reload rules with custom exceptions, which smells, but I had to ask :)

> 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 at 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)