[Red Hat JIRA] (WFLY-13595) MP REST client causes classloader leak on undeploy
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13595?page=com.atlassian.jira.plugi... ]
James Perkins updated WFLY-13595:
---------------------------------
Fix Version/s: 23.0.0.Beta1
> MP REST client causes classloader leak on undeploy
> --------------------------------------------------
>
> Key: WFLY-13595
> URL: https://issues.redhat.com/browse/WFLY-13595
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Affects Versions: 20.0.0.Final
> Reporter: Richard DiCroce
> Assignee: Alessio Soldano
> Priority: Major
> Fix For: 23.0.0.Beta1
>
>
> I have an application that uses CDI and JAX-RS but not MP REST. The MP subsystems aren't even part of the WildFly configuration. Nonetheless, the MP REST client is added to the deployment and creates a classloader leak when the application is undeployed.
> See below for the paths to GC root, as determined using a heap dump analyzed by Eclipse MAT. In particular, note that org.jboss.resteasy.microprofile.client.RestClientExtension keeps a static reference to the CDI BeanManager.
> Workaround: add an exclusion in jboss-deployment-structure.xml to prevent the org.jboss.resteasy.resteasy-client-microprofile module from being added to the deployment.
> {noformat}
> Class Name | Shallow Heap | Retained Heap
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> | |
> com.sg.sciq.jpa.entity.QStore @ 0xfc8913f0 | 120 | 10,704
> '- store class com.sg.sciq.jpa.entity.QStore @ 0xe53d5af0 | 24 | 10,816
> '- [459] java.lang.Object[5120] @ 0xe702af00 | 20,496 | 3,166,624
> '- elementData java.util.Vector @ 0xe4677e88 | 32 | 3,166,656
> '- classes org.jboss.modules.ModuleClassLoader @ 0xe4677208 | 88 | 3,654,184
> '- moduleClassLoader org.jboss.as.weld.discovery.WeldClassFileServices @ 0xe4d09bb8 | 24 | 24
> '- value java.util.HashMap$Node @ 0xe507ed10 | 32 | 32
> '- [63] java.util.HashMap$Node[128] @ 0xe4df06e8 | 528 | 2,904
> '- table java.util.HashMap @ 0xe4df06b8 | 48 | 2,984
> '- services org.jboss.weld.bootstrap.api.helpers.SimpleServiceRegistry @ 0xe4df06a8 | 16 | 3,000
> '- services org.jboss.weld.manager.BeanManagerImpl @ 0xe4df0610 | 152 | 7,848
> '- manager org.jboss.weld.bean.builtin.BeanManagerProxy @ 0xe4df0c90 | 24 | 24
> '- manager class org.jboss.resteasy.microprofile.client.RestClientExtension @ 0xe4df0c20 | 8 | 56
> '- [0] java.lang.Object[10] @ 0xe46ec028 | 56 | 80
> '- elementData java.util.Vector @ 0xe46ec008 | 32 | 112
> '- classes org.jboss.modules.ModuleClassLoader @ 0xe46ebea8 | 88 | 3,240
> '- moduleClassLoader org.jboss.modules.Module @ 0xe47d1348 | 56 | 30,296
> '- module org.jboss.modules.ModuleLoader$FutureModule @ 0xe4a65790 | 24 | 24
> '- val java.util.concurrent.ConcurrentHashMap$Node @ 0xe4a65770 | 32 | 56
> '- [352] java.util.concurrent.ConcurrentHashMap$Node[512] @ 0xe08491f0 | 2,064 | 19,088
> '- table java.util.concurrent.ConcurrentHashMap @ 0xe0487188 | 64 | 19,152
> '- moduleMap org.jboss.modules.LocalModuleLoader @ 0xe0487150 | 56 | 22,120
> |- moduleLoader org.jboss.modules.Module @ 0xe014b580 | 56 | 9,336
> |- moduleLoader org.jboss.modules.Module @ 0xe017c0e0 | 56 | 58,440
> |- moduleLoader org.jboss.modules.Module @ 0xe034f7c8 | 56 | 28,576
> |- moduleLoader org.jboss.modules.Module @ 0xe05f8e50 | 56 | 41,160
> |- moduleLoader org.jboss.modules.Module @ 0xe06db838 | 56 | 72,288
> |- moduleLoader org.jboss.modules.Module @ 0xe06f42e0 | 56 | 20,720
> |- moduleLoader org.jboss.modules.Module @ 0xe0741d58 | 56 | 56,712
> |- moduleLoader org.jboss.modules.Module @ 0xe0979ec8 | 56 | 43,760
> |- moduleLoader org.jboss.modules.Module @ 0xe04a9200 | 56 | 14,000
> |- moduleLoader org.jboss.modules.Module @ 0xe05c9b30 | 56 | 8,704
> |- moduleLoader org.jboss.modules.Module @ 0xe0729200 | 56 | 23,264
> |- moduleLoader org.jboss.modules.Module @ 0xe0941378 | 56 | 54,360
> |- moduleLoader org.jboss.modules.Module @ 0xe032e128 | 56 | 22,832
> |- moduleLoader org.jboss.modules.Module @ 0xe05dbaf0 | 56 | 27,728
> |- INSTANCE class org.jboss.modules.DefaultBootModuleLoaderHolder @ 0xe065cbe0| 8 | 8
> |- moduleLoader org.jboss.modules.Module @ 0xe068b460 | 56 | 20,008
> |- moduleLoader org.jboss.modules.Module @ 0xe0707518 | 56 | 46,848
> |- moduleLoader org.jboss.modules.Module @ 0xe073b5e0 | 56 | 44,880
> |- moduleLoader org.jboss.modules.Module @ 0xe0213738 | 56 | 12,040
> |- moduleLoader org.jboss.modules.Module @ 0xe058c4f0 | 56 | 23,424
> |- moduleLoader org.jboss.modules.Module @ 0xe02f41c8 | 56 | 30,144
> |- moduleLoader org.jboss.modules.Module @ 0xe034f128 | 56 | 27,088
> |- moduleLoader org.jboss.modules.Module @ 0xe0500470 | 56 | 9,912
> |- moduleLoader org.jboss.modules.Module @ 0xe12ceea0 | 56 | 24,648
> '- Total: 24 entries | |
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months
[Red Hat JIRA] (WFWIP-373) :resolve-expression does not resolve encrypted expressions
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFWIP-373?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFWIP-373:
----------------------------------------
Related to this is ReadAttributeHandler.ResolveAttributeHandler which is what handles a true value for the 'resolve' parameter to read-resource or read-attribute.
> :resolve-expression does not resolve encrypted expressions
> ----------------------------------------------------------
>
> Key: WFWIP-373
> URL: https://issues.redhat.com/browse/WFWIP-373
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Priority: Major
>
> The {{:resolve-expression}} operation does not resolve encrypted expressions.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:read-resource
> {
> "outcome" => "success",
> "result" => {
> "default-resolver" => "Default",
> "prefix" => "ENC",
> "resolvers" => [
> {
> "name" => "Default",
> "credential-store" => "credentialstorethree",
> "secret-key" => "secretkey"
> },
> {
> "name" => "resolver2",
> "credential-store" => "credentialstorethree",
> "secret-key" => "secretkey2"
> }
> ]
> }
> }
> [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:create-expression(clear-text=CredentialStoreTwoPassword)
> {
> "outcome" => "success",
> "result" => {"expression" => "${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}"}
> }
> [standalone@localhost:9990 /] :resolve-expression(expression="${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}")
> {
> "outcome" => "success",
> "result" => ":RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB"
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months
[Red Hat JIRA] (WFLY-13595) MP REST client causes classloader leak on undeploy
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13595?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFLY-13595:
--------------------------------------
This is likely resolved by RESTEASY-2832 which will be in WildFly 23.
> MP REST client causes classloader leak on undeploy
> --------------------------------------------------
>
> Key: WFLY-13595
> URL: https://issues.redhat.com/browse/WFLY-13595
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Affects Versions: 20.0.0.Final
> Reporter: Richard DiCroce
> Assignee: Alessio Soldano
> Priority: Major
>
> I have an application that uses CDI and JAX-RS but not MP REST. The MP subsystems aren't even part of the WildFly configuration. Nonetheless, the MP REST client is added to the deployment and creates a classloader leak when the application is undeployed.
> See below for the paths to GC root, as determined using a heap dump analyzed by Eclipse MAT. In particular, note that org.jboss.resteasy.microprofile.client.RestClientExtension keeps a static reference to the CDI BeanManager.
> Workaround: add an exclusion in jboss-deployment-structure.xml to prevent the org.jboss.resteasy.resteasy-client-microprofile module from being added to the deployment.
> {noformat}
> Class Name | Shallow Heap | Retained Heap
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> | |
> com.sg.sciq.jpa.entity.QStore @ 0xfc8913f0 | 120 | 10,704
> '- store class com.sg.sciq.jpa.entity.QStore @ 0xe53d5af0 | 24 | 10,816
> '- [459] java.lang.Object[5120] @ 0xe702af00 | 20,496 | 3,166,624
> '- elementData java.util.Vector @ 0xe4677e88 | 32 | 3,166,656
> '- classes org.jboss.modules.ModuleClassLoader @ 0xe4677208 | 88 | 3,654,184
> '- moduleClassLoader org.jboss.as.weld.discovery.WeldClassFileServices @ 0xe4d09bb8 | 24 | 24
> '- value java.util.HashMap$Node @ 0xe507ed10 | 32 | 32
> '- [63] java.util.HashMap$Node[128] @ 0xe4df06e8 | 528 | 2,904
> '- table java.util.HashMap @ 0xe4df06b8 | 48 | 2,984
> '- services org.jboss.weld.bootstrap.api.helpers.SimpleServiceRegistry @ 0xe4df06a8 | 16 | 3,000
> '- services org.jboss.weld.manager.BeanManagerImpl @ 0xe4df0610 | 152 | 7,848
> '- manager org.jboss.weld.bean.builtin.BeanManagerProxy @ 0xe4df0c90 | 24 | 24
> '- manager class org.jboss.resteasy.microprofile.client.RestClientExtension @ 0xe4df0c20 | 8 | 56
> '- [0] java.lang.Object[10] @ 0xe46ec028 | 56 | 80
> '- elementData java.util.Vector @ 0xe46ec008 | 32 | 112
> '- classes org.jboss.modules.ModuleClassLoader @ 0xe46ebea8 | 88 | 3,240
> '- moduleClassLoader org.jboss.modules.Module @ 0xe47d1348 | 56 | 30,296
> '- module org.jboss.modules.ModuleLoader$FutureModule @ 0xe4a65790 | 24 | 24
> '- val java.util.concurrent.ConcurrentHashMap$Node @ 0xe4a65770 | 32 | 56
> '- [352] java.util.concurrent.ConcurrentHashMap$Node[512] @ 0xe08491f0 | 2,064 | 19,088
> '- table java.util.concurrent.ConcurrentHashMap @ 0xe0487188 | 64 | 19,152
> '- moduleMap org.jboss.modules.LocalModuleLoader @ 0xe0487150 | 56 | 22,120
> |- moduleLoader org.jboss.modules.Module @ 0xe014b580 | 56 | 9,336
> |- moduleLoader org.jboss.modules.Module @ 0xe017c0e0 | 56 | 58,440
> |- moduleLoader org.jboss.modules.Module @ 0xe034f7c8 | 56 | 28,576
> |- moduleLoader org.jboss.modules.Module @ 0xe05f8e50 | 56 | 41,160
> |- moduleLoader org.jboss.modules.Module @ 0xe06db838 | 56 | 72,288
> |- moduleLoader org.jboss.modules.Module @ 0xe06f42e0 | 56 | 20,720
> |- moduleLoader org.jboss.modules.Module @ 0xe0741d58 | 56 | 56,712
> |- moduleLoader org.jboss.modules.Module @ 0xe0979ec8 | 56 | 43,760
> |- moduleLoader org.jboss.modules.Module @ 0xe04a9200 | 56 | 14,000
> |- moduleLoader org.jboss.modules.Module @ 0xe05c9b30 | 56 | 8,704
> |- moduleLoader org.jboss.modules.Module @ 0xe0729200 | 56 | 23,264
> |- moduleLoader org.jboss.modules.Module @ 0xe0941378 | 56 | 54,360
> |- moduleLoader org.jboss.modules.Module @ 0xe032e128 | 56 | 22,832
> |- moduleLoader org.jboss.modules.Module @ 0xe05dbaf0 | 56 | 27,728
> |- INSTANCE class org.jboss.modules.DefaultBootModuleLoaderHolder @ 0xe065cbe0| 8 | 8
> |- moduleLoader org.jboss.modules.Module @ 0xe068b460 | 56 | 20,008
> |- moduleLoader org.jboss.modules.Module @ 0xe0707518 | 56 | 46,848
> |- moduleLoader org.jboss.modules.Module @ 0xe073b5e0 | 56 | 44,880
> |- moduleLoader org.jboss.modules.Module @ 0xe0213738 | 56 | 12,040
> |- moduleLoader org.jboss.modules.Module @ 0xe058c4f0 | 56 | 23,424
> |- moduleLoader org.jboss.modules.Module @ 0xe02f41c8 | 56 | 30,144
> |- moduleLoader org.jboss.modules.Module @ 0xe034f128 | 56 | 27,088
> |- moduleLoader org.jboss.modules.Module @ 0xe0500470 | 56 | 9,912
> |- moduleLoader org.jboss.modules.Module @ 0xe12ceea0 | 56 | 24,648
> '- Total: 24 entries | |
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months
[Red Hat JIRA] (WFWIP-373) :resolve-expression does not resolve encrypted expressions
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFWIP-373?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFWIP-373:
----------------------------------------
Looking at ResolveExpressionHandler it's likely vault expressions would have the same odd output, so this should become a WFCORE and isn't related to the credential-store expression RFE, other than it manifests the existing issue too.
A likely fix is to resolve as it does now using ExpressionResolver.SIMPLE, and if the result is different from the input, then resolve using the full-powered context. If that result is different from the SIMPLE result, just send back the unresolved value, and use OperationContext.addResponseWarning to note the situation. Failing is an option, but that's somewhat a breaking change and probably not worth the hassle, at least not in WF 23.
> :resolve-expression does not resolve encrypted expressions
> ----------------------------------------------------------
>
> Key: WFWIP-373
> URL: https://issues.redhat.com/browse/WFWIP-373
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Priority: Major
>
> The {{:resolve-expression}} operation does not resolve encrypted expressions.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:read-resource
> {
> "outcome" => "success",
> "result" => {
> "default-resolver" => "Default",
> "prefix" => "ENC",
> "resolvers" => [
> {
> "name" => "Default",
> "credential-store" => "credentialstorethree",
> "secret-key" => "secretkey"
> },
> {
> "name" => "resolver2",
> "credential-store" => "credentialstorethree",
> "secret-key" => "secretkey2"
> }
> ]
> }
> }
> [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:create-expression(clear-text=CredentialStoreTwoPassword)
> {
> "outcome" => "success",
> "result" => {"expression" => "${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}"}
> }
> [standalone@localhost:9990 /] :resolve-expression(expression="${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}")
> {
> "outcome" => "success",
> "result" => ":RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB"
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months
[Red Hat JIRA] (WFWIP-373) :resolve-expression does not resolve encrypted expressions
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFWIP-373?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFWIP-373 at 2/19/21 1:42 PM:
-----------------------------------------------------------------
[~dlofthouse] Not resolving is not a bug. It is by design. We should not support resolving via a management API call, and the resolve-expressions op is specifically meant to not do that.
If the credential-store handling is different from vault (e.g. the weird result" => ":RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB") then that is something to fix for this RFE.
If vault behaves the same way, then it's a general, low-priority, bug to not do the weird stripping of the vault equivalent of ENC:
Simply returning the unresolved expression is IMHO ok. IIRC that is what we decided to do, with due consideration first. Doing something else would be an enhancement.
was (Author: brian.stansberry):
[~dlofthouse] Note resolving is not a bug. It is by design. We should not support resolving via a management API call, and the resolve-expressions op is specifically meant to not do that.
If the credential-store handling is different from vault (e.g. the weird result" => ":RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB") then that is something to fix for this RFE.
If vault behaves the same way, then it's a general, low-priority, bug to not do the weird stripping of the vault equivalent of ENC:
Simply returning the unresolved expression is IMHO ok. IIRC that is what we decided to do, with due consideration first. Doing something else would be an enhancement.
> :resolve-expression does not resolve encrypted expressions
> ----------------------------------------------------------
>
> Key: WFWIP-373
> URL: https://issues.redhat.com/browse/WFWIP-373
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Priority: Major
>
> The {{:resolve-expression}} operation does not resolve encrypted expressions.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:read-resource
> {
> "outcome" => "success",
> "result" => {
> "default-resolver" => "Default",
> "prefix" => "ENC",
> "resolvers" => [
> {
> "name" => "Default",
> "credential-store" => "credentialstorethree",
> "secret-key" => "secretkey"
> },
> {
> "name" => "resolver2",
> "credential-store" => "credentialstorethree",
> "secret-key" => "secretkey2"
> }
> ]
> }
> }
> [standalone@localhost:9990 /] /subsystem=elytron/expression=encryption:create-expression(clear-text=CredentialStoreTwoPassword)
> {
> "outcome" => "success",
> "result" => {"expression" => "${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}"}
> }
> [standalone@localhost:9990 /] :resolve-expression(expression="${ENC::RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB}")
> {
> "outcome" => "success",
> "result" => ":RUxZAUMQHrI7PMuvU+0pJ9EgITJmFPWa9iIb5yZ6i9K3mtgnY2kLo3AIL4d/GIeo7GKzSkXB"
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months
[Red Hat JIRA] (WFLY-14107) EJBInvocationStatistics TestCase Failures
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-14107?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-14107:
-----------------------------------
this test has a pass rate of 99.9% (as of 2021-02-19), with 1 failure out of 1588 recent runs. So it has improved after the fixed made last time ( WFLY-10173), but the intermittent failure still exists. I suggest we igore this test.
> EJBInvocationStatistics TestCase Failures
> -----------------------------------------
>
> Key: WFLY-14107
> URL: https://issues.redhat.com/browse/WFLY-14107
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Cheng Fang
> Priority: Major
>
> I have been seeing test failures running this test locally quite often:
> {code:java}
> [ERROR] Failures:
> [ERROR] EjbInvocationStatisticsTestCase.testSingletonWaitTime:147->validateWaitTimeStatistic:175 Expecting wait-time attribute value > 0, but got {
> "async-methods" => undefined,
> "business-local" => undefined,
> "business-remote" => ["org.jboss.as.test.integration.ejb.management.deployments.BusinessInterface"],
> "component-class-name" => "org.jboss.as.test.integration.ejb.management.deployments.WaitTimeSingletonBean",
> "concurrency-management-type" => undefined,
> "declared-roles" => [],
> "depends-on" => undefined,
> "execution-time" => 2L,
> "init-on-startup" => false,
> "invocations" => 4L,
> "jndi-names" => [
> "java:app/ejb-management/WaitTimeSingletonBean!org.jboss.as.test.integration.ejb.management.deployments.BusinessInterface",
> "java:module/WaitTimeSingletonBean!org.jboss.as.test.integration.ejb.management.deployments.BusinessInterface",
> "java:global/ejb-management/WaitTimeSingletonBean",
> "java:app/ejb-management/WaitTimeSingletonBean",
> "java:global/ejb-management/WaitTimeSingletonBean!org.jboss.as.test.integration.ejb.management.deployments.BusinessInterface",
> "java:module/WaitTimeSingletonBean"
> ],
> "methods" => {
> "doIt" => {
> "execution-time" => 2L,
> "invocations" => 3L,
> "wait-time" => 0L
> },
> "remove" => {
> "execution-time" => 0L,
> "invocations" => 1L,
> "wait-time" => 0L
> }
> },
> "peak-concurrent-invocations" => 1L,
> "run-as-role" => undefined,
> "security-domain" => "other",
> "timeout-method" => "private void org.jboss.as.test.integration.ejb.management.deployments.WaitTimeSingletonBean.timeout(javax.ejb.Timer)",
> "timers" => [],
> "transaction-type" => "BEAN",
> "wait-time" => 0L,
> "service" => {"timer-service" => undefined}
> } {code}
> My desktop PC is quite fast so I don't know if this means invocations are passing faster than the test expects.
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months
[Red Hat JIRA] (WFWIP-379) secret-key-creadential-store reload results in an error
by Ondrej Kotek (Jira)
Ondrej Kotek created WFWIP-379:
----------------------------------
Summary: secret-key-creadential-store reload results in an error
Key: WFWIP-379
URL: https://issues.redhat.com/browse/WFWIP-379
Project: WildFly WIP
Issue Type: Bug
Components: Security
Reporter: Ondrej Kotek
Assignee: Darran Lofthouse
The {[reload}} operation of the {{secret-key-creadential-store}} resource results in an error
{noformat}
[domain@localhost:9990 /] /subsystem=elytron/secret-key-credential-store=a:add(path=ax)
{"outcome" => "success"}
[domain@localhost:9990 /] /subsystem=elytron/secret-key-credential-store=a:read-aliases
{
"outcome" => "success",
"result" => ["key"]
}
[domain@localhost:9990 /] /subsystem=elytron/secret-key-credential-store=a:reload
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.ClassCastException: class org.wildfly.extension.elytron.SecretKeyCredentialStoreDefinition$SecretKeyDoohickey cannot be cast to clas
s org.wildfly.extension.elytron.CredentialStoreResourceDefinition$CredentialStoreDoohickey (org.wildfly.extension.elytron.SecretKeyCredentialStoreDefinition$SecretKeyDoohickey and org.wildfly.extension.elytron.C
redentialStoreResourceDefinition$CredentialStoreDoohickey are in unnamed module of loader 'org.wildfly.extension.elytron(a)15.0.0.Beta1-SNAPSHOT' @50dfce09)",
"rolled-back" => true
}
{noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 2 months