[JBoss JIRA] (WFCORE-3479) Deploying an empty deployment and adding content later fails in a composite
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugi... ]
Kabir Khan reassigned WFCORE-3479:
----------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
> Key: WFCORE-3479
> URL: https://issues.jboss.org/browse/WFCORE-3479
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.10.Final
> Reporter: Kabir Khan
> Assignee: ehsavoie Hugonnet
> Fix For: 4.0.0.Beta1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem.
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{"empty" => true}]
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [
> {
> "target-path" => "index.html",
> "input-stream-index" => 0
> },
> {
> "target-path" => "index2.html",
> "input-stream-index" => 1
> }
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
> "execute-for-coordinator" => true
> }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
> 0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
> 0x04, 0x05, 0x9d, 0x82
> },
> "archive" => false
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "runtime-name" => undefined
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
> "execute-for-coordinator" => true
> }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-2" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-3" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-4" => {
> "outcome" => "failed",
> "rolled-back" => true
> }
> },
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
> "rolled-back" => true,
> "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
> "rolled-back" => true
> },
> "step-2" => {"outcome" => undefined}
> },
> "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
> "operation" => "composite",
> "steps" => [
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "enabled" => true,
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "runtime-name" => "test.war",
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "archive" => false
> }]
> }
> ],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-9428) Distributed shared web sessions can passivate prematurely
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9428:
-------------------------------
Priority: Major (was: Critical)
> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
> Key: WFLY-9428
> URL: https://issues.jboss.org/browse/WFLY-9428
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-9428) Distributed shared web sessions can passivate prematurely
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9428:
-------------------------------
Description:
When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
was:
When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus expire prematurely.
To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
> Key: WFLY-9428
> URL: https://issues.jboss.org/browse/WFLY-9428
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-9428) Distributed shared web sessions can passivate prematurely
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9428:
-------------------------------
Summary: Distributed shared web sessions can passivate prematurely (was: Distributed shared web sessions can expire prematurely)
> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
> Key: WFLY-9428
> URL: https://issues.jboss.org/browse/WFLY-9428
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus expire prematurely.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3458) External CS, PKCS11 can't be configured with externalPath
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugi... ]
Ilia Vassilev edited comment on WFCORE-3458 at 12/21/17 4:44 PM:
-----------------------------------------------------------------
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
When location is not set for most common filebased keystore types (JKS, JCEKS and PKCS12), Elytron will throw exception.
was (Author: ivassile):
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
When location is not set for most common filebased keystore types (JKS,
JCEKS and PKCS12), Elytron will throw exception.
> External CS, PKCS11 can't be configured with externalPath
> ----------------------------------------------------------
>
> Key: WFCORE-3458
> URL: https://issues.jboss.org/browse/WFCORE-3458
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 4.0.0.Alpha4
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> ... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361)
> at java.nio.file.Files.newByteChannel(Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> ... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
> private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
> KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
> keyStore = getKeyStoreInstance("JCEKS");
> externalStorage = new ExternalStorage();
> try {
> final char[] storePassword = getStorePassword(protectionParameter);
> if (keyContainingKeyStoreLocation != null) {
> try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
> keyContainingKeyStore.load(is, storePassword);
> }
> } else {
> // keystore without file (e.g. PKCS11)
> synchronized (EmptyProvider.getInstance()) {
> keyContainingKeyStore.load(null, storePassword);
> }
> }
> externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
> } catch(IOException | GeneralSecurityException e) {
> throw log.cannotInitializeCredentialStore(e);
> }
> }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3458) External CS, PKCS11 can't be configured with externalPath
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3458?page=com.atlassian.jira.plugi... ]
Ilia Vassilev edited comment on WFCORE-3458 at 12/21/17 4:43 PM:
-----------------------------------------------------------------
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
When location is not set for most common filebased keystore types (JKS,
JCEKS and PKCS12), Elytron will throw exception.
was (Author: ivassile):
In Elytron subsystem, remove the requirement: "if location is not set in CLI, default credential-store name is used as location"
> External CS, PKCS11 can't be configured with externalPath
> ----------------------------------------------------------
>
> Key: WFCORE-3458
> URL: https://issues.jboss.org/browse/WFCORE-3458
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 4.0.0.Alpha4
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Critical
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> ... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361)
> at java.nio.file.Files.newByteChannel(Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> ... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
> private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
> KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
> keyStore = getKeyStoreInstance("JCEKS");
> externalStorage = new ExternalStorage();
> try {
> final char[] storePassword = getStorePassword(protectionParameter);
> if (keyContainingKeyStoreLocation != null) {
> try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
> keyContainingKeyStore.load(is, storePassword);
> }
> } else {
> // keystore without file (e.g. PKCS11)
> synchronized (EmptyProvider.getInstance()) {
> keyContainingKeyStore.load(null, storePassword);
> }
> }
> externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
> } catch(IOException | GeneralSecurityException e) {
> throw log.cannotInitializeCredentialStore(e);
> }
> }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months