[ https://issues.jboss.org/browse/WFCORE-3747?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-3747: ------------------------------------------ The issue here is a little more complex than the description. The type attribute does not actually default to JCEKS, it does genuinely default to undefined / null. The problem is there is a second value 'keyStoreType which is used to specify the type of the key store used by the credential store which is independent of the actual key store implementation, this value can be set within the implementation-properties. Any value set in the implementation-properties takes precedence. If the type attribute is not defined or the type attribute is set to KeyStoreCredentialStore then if (and only if) no keyStoreType is specified we assume the keyStoreType should be JCEKS. _Note: We never set the type value to JCEKS, that realms set to null._ Now in relation to the location attribute that actually checks if the 'keyStoreType' as been set to one of JKS, JCEKS, and PKCS12 after the evaluation described above. This means it would not be a simple update to the description above. I think I need to double check some configuration options to verify a null type really does make sense. Other than that I think this is a sign this is a complex resource with some in-depth validation requirements which make automatic validation difficult (TBH any validation applied to a Map based configuration is always error prone). We may want to revisit the resource definition at some point as it is also not following the pattern we used for other resources in the subsystem. As an example for other capabilities we provide in our subsystem we provide dedicated resources for each implementation, this means our configuration is very focused on the requirements of that implementation allowing us to both declare the validation and execute it. We then additionally add a resource for custom implementations with generic configuration that we do not validate. This may be what we need to do here - split the resource into two or more resources and deprecate this one. On other resources where a capabilities results in exposing the same management operations on multiple resources we use a decorator pattern to add those additional methods, that same pattern would still be applicable to credential stores. In the meantime I am documenting the credential store under WFLY-11101 as we have identified community documentation is missing. Unless we end up with some free time towards the end of WildFly 18 now is not the time to refactor this resource so instead we may need to rely on the documentation rather than the model description. -- This message was sent by Atlassian Jira (v7.12.1#712002)