[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Jan Kalina edited comment on ELY-1295 at 1/4/18 6:03 AM:
---------------------------------------------------------
Reason of *Get Key failed: Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.7.1" to algorithm name - but by OID repository it is "pkcs7-data" - not a key type...
Looks like IBM JDK has problem to store password credential into PKCS12 keystore, as it tries to decode it as key...
was (Author: honza889):
Reason of *Get Key failed: Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.7.1" to algorithm name - but by OID repository it is "pkcs7-data" - not a key type...
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Peter Palaga
> Assignee: Jan Kalina
> Priority: Critical
> Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Jan Kalina edited comment on ELY-1295 at 1/4/18 5:56 AM:
---------------------------------------------------------
Reason of *Get Key failed: Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.7.1" to algorithm name - but by OID repository it is "pkcs7-data" - not a key type...
was (Author: honza889):
Reason of *Get Key failed: Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.12.1.3" to algorithm name (by OID repository it should be "pbeWithSHA1And3-KeyTripleDES-CBC").
PBE with SHA1 + SHA3 is not supported by IBM by this - one of following (from similar ones) should work ok:
* PBEWithSHAAndDES
* PBEWithSHAAndRC2
* PBEWithSHAAnd40BitRC4
* PBEWithSHAAnd128BitRC4
* PBEWithSHAAnd3KeyTripleDES
* PBEWithSHAAnd2KeyTripleDES
* PBEWithSHAAnd40BitRC2
* PBEWithSHAAnd128BitRC2
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Peter Palaga
> Assignee: Jan Kalina
> Priority: Critical
> Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1295:
---------------------------------
Reason of *Get Key failed: Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.12.1.3" to algorithm name (by OID repository it should be "pbeWithSHA1And3-KeyTripleDES-CBC").
PBE with SHA1 + SHA3 is not supported by IBM by this - one of following (from similar ones) should work ok:
* PBEWithSHAAndDES
* PBEWithSHAAndRC2
* PBEWithSHAAnd40BitRC4
* PBEWithSHAAnd128BitRC4
* PBEWithSHAAnd3KeyTripleDES
* PBEWithSHAAnd2KeyTripleDES
* PBEWithSHAAnd40BitRC2
* PBEWithSHAAnd128BitRC2
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Peter Palaga
> Assignee: Jan Kalina
> Priority: Critical
> Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFCORE-3489) CLI completion does not work correctly inside of control flow commands
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugi... ]
Erich Duda updated WFCORE-3489:
-------------------------------
Description:
When you use control flow constructs consisting of more commands (e.g. {{for-done}}) CLI completion helper should offer commands based on the current context. So if you type {{for}} command, CLI completion should offer {{done}} command. The same applies for other constructs like {{if-else}}, {{try-catch-finally}} and so on.
However if you use these composite operations inside of other composite operations, the following situation occurs.
{code}
[standalone@embedded /] for var in :read-resource
[standalone@embedded /] try
[standalone@embedded /] <TAB>
: cd connect deployment-overlay help module read-attribute set undeploy
alias clear connection-info done history patch read-operation stop-embedded-server unset
attachment command deploy echo if pwd reload try version
batch command-timeout deployment-info echo-dmr ls quit run-batch unalias
{code}
As you can see the completion helper offers a {{try}} command although it should offer {{catch}} command.
This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called. The same applies also for other control flow commands.
was:
The issue appears when you write following commands into the CLI.
{code}
[standalone@embedded /] for var in :read-resource
[standalone@embedded /] try
[standalone@embedded /] <TAB>
: cd connect deployment-overlay help module read-attribute set undeploy
alias clear connection-info done history patch read-operation stop-embedded-server unset
attachment command deploy echo if pwd reload try version
batch command-timeout deployment-info echo-dmr ls quit run-batch unalias
{code}
As you can see the completion helper offers a {{try}} command although it should offer {{catch}} command.
This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
The same applies also for other control flow commands such as {{if-else-endif}}
> CLI completion does not work correctly inside of control flow commands
> ----------------------------------------------------------------------
>
> Key: WFCORE-3489
> URL: https://issues.jboss.org/browse/WFCORE-3489
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha5
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> When you use control flow constructs consisting of more commands (e.g. {{for-done}}) CLI completion helper should offer commands based on the current context. So if you type {{for}} command, CLI completion should offer {{done}} command. The same applies for other constructs like {{if-else}}, {{try-catch-finally}} and so on.
> However if you use these composite operations inside of other composite operations, the following situation occurs.
> {code}
> [standalone@embedded /] for var in :read-resource
> [standalone@embedded /] try
> [standalone@embedded /] <TAB>
> : cd connect deployment-overlay help module read-attribute set undeploy
> alias clear connection-info done history patch read-operation stop-embedded-server unset
> attachment command deploy echo if pwd reload try version
> batch command-timeout deployment-info echo-dmr ls quit run-batch unalias
> {code}
> As you can see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called. The same applies also for other control flow commands.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFCORE-3489) CLI completion does not work correctly inside of control flow commands
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugi... ]
Erich Duda updated WFCORE-3489:
-------------------------------
Summary: CLI completion does not work correctly inside of control flow commands (was: CLI completion does not work correctly for control flow commands inside of for loop)
> CLI completion does not work correctly inside of control flow commands
> ----------------------------------------------------------------------
>
> Key: WFCORE-3489
> URL: https://issues.jboss.org/browse/WFCORE-3489
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha5
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> The issue appears when you write following commands into the CLI.
> {code}
> [standalone@embedded /] for var in :read-resource
> [standalone@embedded /] try
> [standalone@embedded /] <TAB>
> : cd connect deployment-overlay help module read-attribute set undeploy
> alias clear connection-info done history patch read-operation stop-embedded-server unset
> attachment command deploy echo if pwd reload try version
> batch command-timeout deployment-info echo-dmr ls quit run-batch unalias
> {code}
> As you can see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
> The same applies also for other control flow commands such as {{if-else-endif}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFCORE-3489) CLI completion does not work correctly for control flow commands inside of for loop
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugi... ]
Erich Duda commented on WFCORE-3489:
------------------------------------
You're right I will update the description.
> CLI completion does not work correctly for control flow commands inside of for loop
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-3489
> URL: https://issues.jboss.org/browse/WFCORE-3489
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha5
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> The issue appears when you write following commands into the CLI.
> {code}
> [standalone@embedded /] for var in :read-resource
> [standalone@embedded /] try
> [standalone@embedded /] <TAB>
> : cd connect deployment-overlay help module read-attribute set undeploy
> alias clear connection-info done history patch read-operation stop-embedded-server unset
> attachment command deploy echo if pwd reload try version
> batch command-timeout deployment-info echo-dmr ls quit run-batch unalias
> {code}
> As you can see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
> The same applies also for other control flow commands such as {{if-else-endif}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild fails on IBM JDK
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas updated ELY-1298:
------------------------------
Priority: Critical (was: Major)
> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
> Key: ELY-1298
> URL: https://issues.jboss.org/browse/ELY-1298
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Reporter: Peter Palaga
> Priority: Critical
> Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with
> * GssapiCompatibilitySuiteChild
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFCORE-3489) CLI completion does not work correctly for control flow commands inside of for loop
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3489:
----------------------------------------------
What you are observing is not specific to the for loop, try/if are already showing the same behaviour.
> CLI completion does not work correctly for control flow commands inside of for loop
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-3489
> URL: https://issues.jboss.org/browse/WFCORE-3489
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha5
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> The issue appears when you write following commands into the CLI.
> {code}
> [standalone@embedded /] for var in :read-resource
> [standalone@embedded /] try
> [standalone@embedded /] <TAB>
> : cd connect deployment-overlay help module read-attribute set undeploy
> alias clear connection-info done history patch read-operation stop-embedded-server unset
> attachment command deploy echo if pwd reload try version
> batch command-timeout deployment-info echo-dmr ls quit run-batch unalias
> {code}
> As you can see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
> The same applies also for other control flow commands such as {{if-else-endif}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months