[WFLY-17451] Register a requirement for the filter capability in the …#1
[WFLY-17451] Register a requirement for the filter capability in the …#1bstansberry wants to merge 1 commit into
Conversation
…Stage.MODEL handling for adding a filter-ref. Unfortunately, Galleon feature spec generation won't let us record it via FilterResourceRegistration. Also, statically parameterize FilterRefDefinition and FilterRefAdd instances so they know if they are for direct children of 'host' or for children of 'location'
| .addCapabilities(capability.getDefinition()) | ||
| // TODO resolve problem generating a feature spec when this is used | ||
| //.addRequirement(capability.getName(), capability.getDynamicNameMapper(), | ||
| // FilterCapabilities.FILTER_CAPABILITY.getName(), FilterCapabilities.FILTER_CAPABILITY.getDynamicNameMapper()) |
There was a problem hiding this comment.
^^^ would be the ideal way to record that a filter-ref has a requirement for a filter because it results in the info being stored in the ManagementResourceRegistration, where users / tools can learn about the relationship without even adding the undertow subsystem; they just need to add the extension.
If the information was recorded at this point, the kernel code would use it in Stage.MODEL when handling an 'add' op for a filter-ref in order to perform a model consistency check.
But building the Galleon feature pack fails when this is used. So we need to go for next best by overriding FilterRefAdd.recordCapabilitiesAndRequirements below.
| FilterCapabilities.FILTER_CAPABILITY.getDynamicNameMapper(), | ||
| FilterCapabilities.FILTER_CAPABILITY.getName()); | ||
| filterRefRecorder.addCapabilityRequirements(context, resource, null); | ||
| } |
There was a problem hiding this comment.
This method executes in OperationContext.Stage.MODEL, when the 'add' operation for the filter-ref is being executed. This means it records the requirement for the filter before the model consistency checks are performed, so those checks can detect any errors and fail if the config is wrong.
In particular, if the server is running in --admin-only mode, those checks are still run and will report failures, versus the current code that just does service wiring in the performRuntime method. The performRuntime method does not execute in an --admin-only server, so if a user made a mistake adding a filter-ref in an --admin-only server it would not be detected until they later try and boot the server.
[WFLY-21866] For testsuite/layers do no use a feature-pack that provi…
1 participant
…Stage.MODEL handling for adding a filter-ref.
Unfortunately, Galleon feature spec generation won't let us record it via FilterResourceRegistration.
Also, statically parameterize FilterRefDefinition and FilterRefAdd instances so they know if they are for direct children of 'host' or for children of 'location'