Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-1953

Elytron allow-resource-service-restart=true handling

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • None
    • 3.0.0.Alpha11
    • Management
    • None

      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

      [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
      }
      

      And exception in server log

      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)
      

      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

              Unassigned Unassigned
              mchoma@redhat.com Martin Choma
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: