[JBoss JIRA] (WFLY-7743) Infinite wildfly boot on StartException in service start
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7743?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7743:
-----------------------------
Summary: Infinite wildfly boot on StartException in service start (was: Infinite wildfly boot on properties-realm start exception)
> Infinite wildfly boot on StartException in service start
> --------------------------------------------------------
>
> Key: WFLY-7743
> URL: https://issues.jboss.org/browse/WFLY-7743
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7741) JUnit Assumptions with assume are broken in arq testcase for @BeforeClass and @AfterClass
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-7741?page=com.atlassian.jira.plugin.... ]
Chao Wang resolved WFLY-7741.
-----------------------------
Assignee: Chao Wang
Resolution: Rejected
The problem here is that it can not use assumption in @AfterClass method.
Only in @BeforeClass method is acceptable behavior
> JUnit Assumptions with assume are broken in arq testcase for @BeforeClass and @AfterClass
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-7741
> URL: https://issues.jboss.org/browse/WFLY-7741
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> 1. Write a simple unit test with JUnit assumptions in @BeforeClass and @AfterClass methods.
> {code:java}
> @RunWith(Arquillian.class)
> public class ArqAssumeInBeforeClassTestCase {
> @BeforeClass
> public static void beforeClass() throws IOException, InterruptedException {
> Assume.assumeTrue(false); // this should skip
> }
> @AfterClass
> public static void afterClass() throws IOException {
> Assume.assumeTrue(false); // this should skip
> }
> @Test
> public void test() {
> }
> }
> {code}
> 2. Inside wildfly/testsuite run command:
> mvn clean install -Dts.noSmoke -Dts.basic -Dtest=ArqAssumeInBeforeClassTestCase (for example in basic ts)
> 3. You will see the AssumptionViolatedException from @BeforeClass and @AfterClass methods as:
> {noformat}
> T E S T S
> -------------------------------------------------------
> Running org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.006 sec <<< FAILURE! - in org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase
> org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase Time elapsed: 0.005 sec <<< ERROR!
> org.junit.AssumptionViolatedException: got: <false>, expected: is <true>
> at org.junit.Assume.assumeThat(Assume.java:95)
> at org.junit.Assume.assumeTrue(Assume.java:41)
> at org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase.beforeClass(ArqAssumeInBeforeClassTestCase.java:17)
> org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase Time elapsed: 0.006 sec <<< ERROR!
> org.junit.AssumptionViolatedException: got: <false>, expected: is <true>
> at org.junit.Assume.assumeThat(Assume.java:95)
> at org.junit.Assume.assumeTrue(Assume.java:41)
> at org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase.afterClass(ArqAssumeInBeforeClassTestCase.java:22)
> Results :
> Tests in error:
> org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase.org.jboss.as.test.integration.deployment.structure.war.ArqAssumeInBeforeClassTestCase
> Run 1: ArqAssumeInBeforeClassTestCase.beforeClass:17 » AssumptionViolated got: <false...
> Run 2: ArqAssumeInBeforeClassTestCase.afterClass:22 » AssumptionViolated got: <false>...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> {noformat}
> However, the executions inside @BeforeClass and @AfterClass methods should simply be skipped.
> Example test https://github.com/soul2zimate/wildfly/commits/ArqAssumeInBeforeClassTest...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7742) CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-7742?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-7742:
-----------------------------------
KeyStores are case-insensitive, so credential stores backed by KeyStores must also be (unless we do some kind of encoding scheme).
I think we should unify on mapping to lowercase by way of the {{ROOT}} locale.
> CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7742
> URL: https://issues.jboss.org/browse/WFLY-7742
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
> {code}
> In csfile001.jceks you can see only "csname001" entry.
> *There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
> {code}
> And now you can use both (csFF and csff) as CredStoreRef alias
> e.g.
> {code}
> /subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
> {code}
> Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
> *NOTE*
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
> {code}
> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> {code}
> *Suggestions for solution*
> * We must unite case (in)sensitive between CS keystore file and CS in memory
> * implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
> * something else
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh Commands
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-2088:
--------------------------------------------
Summary: Enhance CLI to support Aesh Commands
Key: WFCORE-2088
URL: https://issues.jboss.org/browse/WFCORE-2088
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
This is the CLI.next project.
Aesh 1.0 will come with a Command API based on annotations. It makes full sense to redesign part of the existing commands, still offering backward compatibility using this API.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7742) CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7742?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-7742:
-------------------------------
Summary: CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase. (was: CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.)
> CredentialStore resource name and CS alias in memory are case sensitive but CredentialStore aliases are persisted in lowercase.
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7742
> URL: https://issues.jboss.org/browse/WFLY-7742
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
> {code}
> In csfile001.jceks you can see only "csname001" entry.
> *There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
> {code}
> And now you can use both (csFF and csff) as CredStoreRef alias
> e.g.
> {code}
> /subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
> {code}
> Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
> *NOTE*
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
> {code}
> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> {code}
> *Suggestions for solution*
> * We must unite case (in)sensitive between CS keystore file and CS in memory
> * implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
> * something else
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7743) Infinite wildfly boot on properties-realm start exception
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7743?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7743:
-----------------------------
Affects Version/s: 10.1.0.Final
(was: 11.0.0.Alpha1)
> Infinite wildfly boot on properties-realm start exception
> ---------------------------------------------------------
>
> Key: WFLY-7743
> URL: https://issues.jboss.org/browse/WFLY-7743
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7742) CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7742?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-7742:
-------------------------------
Description:
CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
*How to reproduce*
{code}
/subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
{code}
In csfile001.jceks you can see only "csname001" entry.
*There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
{code}
/subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
{code}
And now you can use both (csFF and csff) as CredStoreRef alias
e.g.
{code}
/subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
{code}
Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
*NOTE*
https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
{code}
Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
{code}
*Suggestions for solution*
* We must unite case (in)sensitive between CS keystore file and CS in memory
* implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
* something else
was:
CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
*How to reproduce*
{code}
/subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
{code}
{code}
/subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
{code}
In csfile001.jceks you can see only "csname001" entry.
*What is the biggest problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.*
*NOTE*
https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
{code}
Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
{code}
*Suggestions for solution*
* implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
* add NOTE to documentation
* something else
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-7742
> URL: https://issues.jboss.org/browse/WFLY-7742
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> CredentialStore resource name is case sensitive but CredentialStore alias is convert to lowercase.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=csfile001:add(uri="cr-store://test/csfile001.jceks?store.password=pass123;create.storage=true")
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csname001:add(secret-value=secValue123456)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csNAME001:add(secret-value=secValue987654)
> {code}
> In csfile001.jceks you can see only "csname001" entry.
> *There is biggest problem that in memory are right case sensitive aliases and you can load them. But in backed CS file is only last one in lowercase.*
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csFF:add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=csfile001/alias=csff:add(secret-value=ElytronWrong)
> {code}
> And now you can use both (csFF and csff) as CredStoreRef alias
> e.g.
> {code}
> /subsystem=elytron/key-store=fireflyKS001:add(path=firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=csfile001,alias=csFF})
> {code}
> Another big problem for me is that you have a lot of CS Alias RESOURCES which reference to ONE entry and update value in CS.
> *NOTE*
> https://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html
> {code}
> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> {code}
> *Suggestions for solution*
> * We must unite case (in)sensitive between CS keystore file and CS in memory
> * implement case sensitive (Our implementation looks ok, IMO there is another problem with it...)
> * something else
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7743) Infinite wildfly boot on properties-realm start exception
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7743?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved JBEAP-7654 to WFLY-7743:
-----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7743 (was: JBEAP-7654)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR9)
> Infinite wildfly boot on properties-realm start exception
> ---------------------------------------------------------
>
> Key: WFLY-7743
> URL: https://issues.jboss.org/browse/WFLY-7743
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7736) PersistentIntervalTimerManagementTestCase fails on slower machine
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7736?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-7736:
-----------------------------------
Component/s: EJB
Test Suite
> PersistentIntervalTimerManagementTestCase fails on slower machine
> -----------------------------------------------------------------
>
> Key: WFLY-7736
> URL: https://issues.jboss.org/browse/WFLY-7736
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB, Test Suite
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Priority: Minor
>
> How reproducible:
> 10%, with higher CPU load or slower machine
> Steps to Reproduce:
> 1. ./integration-tests.sh -Dts.noSmoke -Dts.basic -Dtest=PersistentIntervalTimerManagementTestCase
> Actual results:
> Timer should fire twice! expected:<2> but was:<3>
> java.lang.AssertionError: Timer should fire twice! expected:<2> but was:<3>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.jboss.as.test.integration.ejb.timerservice.mgmt.AbstractTimerManagementTestCase.testSuspendAndTrigger(AbstractTimerManagementTestCase.java:149)
> at org.jboss.as.test.integration.ejb.timerservice.mgmt.PersistentIntervalTimerManagementTestCase.testSuspendAndTrigger(PersistentIntervalTimerManagementTestCase.java:73)
> Expected results:
> No failures in test case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months