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

Replace AbstractAddStepHandler.Parameters.addRuntimeCapability with a fit to purpose API

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Done
    • Major
    • 23.0.0.Final
    • None
    • Management
    • None

    Description

      The only use case I see for AbstractAddStepHandler.Parameters.addRuntimeCapability is the undertow subsystem ServerAdd scenario (see [1]).

      The ResourceDefinition records two capabilities with the MRR; these must be recorded there so they appear as possible capabilities when generating Galleon feature-specs or when producing error messages for missing capability errors. But only one of the two should always be registered when a resource is added; whether the other is registered depends on configuration values. So:

      1) ServerAdd passes the 'always recorded' capability to Parameters.addRuntimeCapability.
      2) If Parameters passes any capability to the AbstractAddStepHandler constructor, then AbstractAddStepHandler.recordCapabilitiesAndRequirements disables adding any capabilities from the MRR.
      3) Since only 1 cap was provided, the 2nd one available from the MRR is not recorded.
      4) To get the 2nd one recorded, ServerAdd overrides recordCapabilitiesAndRequirements to call the superclass impl, and then executes logic to add the 2nd one if appropriate.

      This is overly convoluted and unintuitive.

      WFCORE-6142 aims to remove the existing deprecated Parameters.addRuntimeCapability methods, but we should do something cleaner to handle the ServerAdd usage pattern.

      I propose

      1) adding a Parameters.addRuntimeCapability(RuntimeCapability cap, BiConsumer<OperationContext, Resource> recorder) method.
      2) AbstractAddStepHandler maintains an instance field Map<RuntimeCapability, BiConsumer<OperationContext, Resource>>
      3) In recordCapabilitiesAndRequirements it always iterates through all the MRR caps. For each it checks the map from 2). If it finds a entry it calls the given BiConsumer; otherwise it executes the usual code.

      ServerAdd would use this by calling Parameters.addRuntimeCapability(CommonWebServer.CAPABILITY, ServerAdd::themethod)

      Basically, OSHs with special requirements just pass in a function with the needed registration behavior for the relevant capability instead of trying to work around the default behavior.

      [1] https://github.com/wildfly/wildfly/blob/main/undertow/src/main/java/org/wildfly/extension/undertow/ServerAdd.java

      Attachments

        Activity

          People

            pferraro@redhat.com Paul Ferraro
            bstansbe@redhat.com Brian Stansberry
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: