[ https://issues.jboss.org/browse/WFCORE-3350?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3350: ------------------------------------- Description: This cloned from WFCORE-3041 but I'm redefining it from being an annoying symptom of a larger problem to being a general problem with an incorrect management API. I'm filing it as a Blocker as we do not want to ship a .GA release with a broken API that we can't readily fix. Here's my analysis of what's wrong with this API from WFCORE-3041: tl;dr; skip to #5. 1) This resource is an effective singleton, because creating more than one will result in a failure due to trying to register POLICY_RUNTIME_CAPABILITY more than once. a) The resource description doesn't state the max occurrences of the resource type is 1. The fact that's missing is a Major at worst. b) If the resource type isn't meant to be a singleton, we have at least a Critical, because the POLICY_RUNTIME_CAPABILITY handling is preventing more than one. 2) Despite being an effective singleton, the resource can have a dynamic name. That's odd. Now we're starting to approach Blocker territory because this is odd, we want API to be correct in WildFly .Final releases, and we can't change things incompatibly thereafter. 3) The reason the resource can have a dynamic name is there has to be a "default policy" and instead of making the resource a singleton with a static name and making the default-policy attribute required, instead there's this weird thing where if default-policy is not configured we use the resource name instead. Not a clear Blocker in and of itself, but again getting into blocker territory because we want our API right in WildFly .Final releases, and we can't change things incompatibly thereafter. 4) The 'default-policy' attribute is actually a model reference, referring to one of the elements in the sibling jacc-policy or custom-policy lists. Typically we would want to use a capability reference for this kind of model ref, but we can't here: a) Doing so would require unique names for the elements across the 2 lists. Which doesn't sound like much of a problem, but isn't something we can't impose after WF 11 Final. b) This business of the value of the last attribute of the resource name being the capability ref isn't something describable. I do not want to support that kind of thing in our management model and our provisioning tooling; i.e. if we have this kind of usage it likely precludes using a capability reference for it. 5) Digging more after writing all the above, I can't see what the point of the jacc-policy and custom-policy lists is anyway. The code is going to work out the default policy, either from the attribute or the resource name. Then it is going to search the jacc-policy list and then the custom-policy list looking for an element whose name matches. As soon as it finds a match it stops. All other elements are irrelevant. So what's the point of these lists? Why doesn't jacc-policy just store a single item, and custom-policy stores a single item, with both attributes required but are alternatives to each other? And then since only one policy can be declared the whole default-policy business goes away. All of the above sounds complicated, but in the end I think the simplest fix is #5 which is fairly easy. We can also decide about #2 (giving the resource a fixed name) but given where we are in the release cycle I think not changing that makes sense. It's not a major flaw to allow a user to provide part of the name of a singleton resource. ============================ Here's the original report from [~claudio4j] of *a* specific problem this introduces: subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters. {code} /profile=full/subsystem=elytron/policy=policy_test:add { "outcome" => "failed", "result" => undefined, "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}}, "rolled-back" => true, "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => { "outcome" => "failed", "failure-description" => "Could find policy provider with name [policy_test]", "rolled-back" => true }}}}}} } {code} To add is necessary to inform either custom-policy or jacc-policy {code} /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}]) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } }}}}}} } {code} There is also a problem related to "default-policy" being set to a non existent policy. was: subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters. {code} /profile=full/subsystem=elytron/policy=policy_test:add { "outcome" => "failed", "result" => undefined, "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}}, "rolled-back" => true, "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => { "outcome" => "failed", "failure-description" => "Could find policy provider with name [policy_test]", "rolled-back" => true }}}}}} } {code} To add is necessary to inform either custom-policy or jacc-policy {code} /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}]) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } }}}}}} } {code} There is also a problem related to "default-policy" being set to a non existent policy. -- This message was sent by Atlassian JIRA (v7.5.0#75005)