New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFCORE-2671][JBEAP-10328] key-managers to key-manager, key-manager:init() #146
[WFCORE-2671][JBEAP-10328] key-managers to key-manager, key-manager:init() #146
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving paperwork
@@ -102,7 +102,7 @@ | |||
static final String KEY_MANAGERS_CAPABILITY = CAPABILITY_BASE + "key-managers"; | |||
|
|||
static final RuntimeCapability<Void> KEY_MANAGERS_RUNTIME_CAPABILITY = RuntimeCapability | |||
.Builder.of(KEY_MANAGERS_CAPABILITY, true, KeyManager[].class) | |||
.Builder.of(KEY_MANAGERS_CAPABILITY, true, InjectedValue.class) // InjectedValue<KeyManager[]> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I am not completely sure about this one - by switching to InjectedValue we are loosing the capability typing. I think we may need to see if we have alternatives that can avoid loosing the type information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if I add special injector type, like KeyManagersInjector
? Will it be sufficient solution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@darranl Will be suggested solution sufficient?
Edit: no, because it would require to know our KeyManagerInjector to implement own capability provider
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still thinking about this one, I don't think we should loose the type information from the capability - I think we need to find an alternative to handle this.
…ng singleton deployment primary->backup transition
…own in CredentialStoreResource
[WFCORE-2672] JDBC Realm Validation
[WFCORE-2730] allow empty target-name and action in permission
Fix for WFCORE-2798. CLI, cd command --no-validation handling
WFCORE-2795: Added a custom validator for Cipher Suites filter in Elytron
ElytronSubsystemMessages#credentialStoreIssueEncountered is never thr…
WFCORE-2794 Wildfly Build Tools 1.2.1.Final
[WFCORE-2790] WildFly Elytron Tool scripts
[WFCORE-2779] Improve help message in module CLI operation
@darranl @honza889 it is marked for the beta, so please give some consideration again |
[WFCORE-2810] Let CapabilityServiceSupport users check for caps
[WFCORE-2807] removed server-side attributes from client-ssl-context
WFCORE-2791 Auto-remove lingering deployment unit attachments following singleton deployment primary->backup transition
I think I will mention in chat - rather than relying on a different type being injected I think we should look at a custom KeyStore implementation so we can still inject a KeyStore but then add a type check and cast. We already have atomic keystores, maybe we can add something that also supports notifications? |
Reworked as requested, tests green, so prepared for merge now. |
https://issues.jboss.org/browse/WFCORE-2671
https://issues.jboss.org/browse/JBEAP-10328
Need to be merged in coordination with wildfly-security-incubator/wildfly#205