[JBoss JIRA] (WFLY-8397) Create test cases for Elytron Principal Transformers
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-8397:
----------------------------------
Summary: Create test cases for Elytron Principal Transformers
Key: WFLY-8397
URL: https://issues.jboss.org/browse/WFLY-8397
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Ondrej Lukas
Create test cases for following Elytron Principal Transformers:
* constant-principal-transformer
* regex-principal-transformer
* regex-validating-principal-transformer
* chained-principal-transformer
Test case for aggregate-principal-transformer cannot developed due to WFCORE-2547. Once meaning of aggregate-principal-transformer will be revisited then appropriate test case will be added.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2351) There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute.
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2351?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFCORE-2351:
-----------------------------------
In the reported case, it can add condition to check service existence as {{if(controller != null)}} before putting element into noLongerMissingServices Map [ContainerStateMonitor.java#L182|https://github.com/wildfly/wildfly-core/b...] to avoid the unnecessary message WFLYCTL0185.
Hi [~brian.stansberry], If you have not started to work on this, I can send the PR with this change.
> There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute.
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2351
> URL: https://issues.jboss.org/browse/WFCORE-2351
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Hynek Švábek
> Assignee: Brian Stansberry
>
> There stuck some required service after unsuccessful command for adding CredentialStore with wrong filled relative-to attribute.
> *Command with wrong filled relative-to attribute*
> {code}
> /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=non.exist.path.resource)
> {code}
> *You can see this log.*
> Especially information about New missing/unsatisfied dependencies:is important and it wouldn't be there.
> {code}
> 16:54:18,809 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "CredStore108")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"non.exist.path.resource\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore108 is missing [jboss.server.path.\"non.exist.path.resource\"]"]
> }
> 16:54:18,810 INFO [org.jboss.as.controller] (management-handler-thread - 8) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.server.path."non.exist.path.resource" (missing) dependents: [service org.wildfly.security.credential-store.CredStore108]
> {code}
> *Now we try process same command without relative-to attribute*
> {code}
> /subsystem=elytron/credential-store=CredStore108:add(uri="cr-store://test/cs108.jceks?create.storage=true", credential-reference={clear-text=pass123})
> {code}
> *Result is success but we can notice this in log:*
> {code}
> 16:55:33,093 INFO [org.jboss.as.controller] (management-handler-thread - 10) WFLYCTL0183: Service status report
> WFLYCTL0185: Newly corrected services:
> service jboss.server.path."non.exist.path.resource" (no longer required)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8396) Remove extra reloads from jca tests
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-8396?page=com.atlassian.jira.plugin.... ]
Petr Kremensky updated WFLY-8396:
---------------------------------
Description:
There are some unnecessary server reloads in jca tests (integration basic module)
org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase
org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase
org.jboss.as.test.integration.jca.metrics.DataSourceCfgMetricUnitTestCase
org.jboss.as.test.integration.jca.metrics.DriverCfgMetricUnitTestCase
org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase
Revisit these and remove all reloads which are not necessary.
was:
There are some unnecessary server reloads in jca tests (integration basic module)
org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase
org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase
org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase
Revisit these and remove all servers which are not necessary.
> Remove extra reloads from jca tests
> -----------------------------------
>
> Key: WFLY-8396
> URL: https://issues.jboss.org/browse/WFLY-8396
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Priority: Minor
>
> There are some unnecessary server reloads in jca tests (integration basic module)
> org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase
> org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase
> org.jboss.as.test.integration.jca.metrics.DataSourceCfgMetricUnitTestCase
> org.jboss.as.test.integration.jca.metrics.DriverCfgMetricUnitTestCase
> org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase
> Revisit these and remove all reloads which are not necessary.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8396) Remove extra reloads from jca tests
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-8396?page=com.atlassian.jira.plugin.... ]
Petr Kremensky moved JBEAP-9649 to WFLY-8396:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8396 (was: JBEAP-9649)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: (was: 7.1.0.DR13)
> Remove extra reloads from jca tests
> -----------------------------------
>
> Key: WFLY-8396
> URL: https://issues.jboss.org/browse/WFLY-8396
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
> Priority: Minor
>
> There are some unnecessary server reloads in jca tests (integration basic module)
> org.jboss.as.test.integration.jca.metrics.RaCfgMetricUnitTestCase
> org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase
> org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase
> Revisit these and remove all servers which are not necessary.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-6771) Add suspend/resume utility for the test suite
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6771?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-6771.
-------------------------------
Resolution: Rejected
This is likely more work than it's worth. The PR was out of date so I just closed it.
> Add suspend/resume utility for the test suite
> ---------------------------------------------
>
> Key: WFLY-6771
> URL: https://issues.jboss.org/browse/WFLY-6771
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Optional
>
> Currently all suspend/resume tests just use the {{suspend}} and {{resume}} operations. A utility would be helpful to keep the suspend and resume functionality consistent. -There should also be a way to wait for the server to fully suspend and/or wait for the server to fully resume.-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-40) Deadlock while logging
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFCORE-40.
-------------------------------
Resolution: Out of Date
If this is still an issue please feel free to reopen.
> Deadlock while logging
> ----------------------
>
> Key: WFCORE-40
> URL: https://issues.jboss.org/browse/WFCORE-40
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior)
> Reporter: Stefan Schueffler
> Assignee: James Perkins
> Priority: Critical
> Attachments: stack_140901_2254
>
>
> We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore...
> The partial stacktrace always is similar to this one:
> {code}
> "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.PrintStream.println(PrintStream.java:806)
> - waiting to lock <0x5ee0adf8> (a java.io.PrintStream)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
> {code}
> While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization).
> If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case.
> My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month