November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6744) Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6744?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-6744. ------------------------------ Resolution: Rejected This is expected behavior. getAttributeNames() is required to throw an ISE if the session is not valid. The ISE should be handled by JSF. > Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found) > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-6744 > URL: https://issues.jboss.org/browse/WFLY-6744 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.CR1 > Environment: Create a cluster with two nodes using standalone-ha.xml (default configuration), create an application with <distributable/> in the web.xml and it must have around 300 requests per seconds and I'm using SSO. > Reporter: Bruno Silva > Assignee: Paul Ferraro > > I reproduced the bug on Wildfly master (https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/artifact/...) . The problem is intermittent, sometimes it works but others not. > {noformat} > 2016-06-17 11:37:32,366 ERROR [io.undertow.servlet.request] (default task-3) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: javax.faces.FacesException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS > at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136) > at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:122) > at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:346) > at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:257) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > 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: java.lang.IllegalStateException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS > at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:56) > at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttributeNames(DistributableSession.java:134) > at io.undertow.servlet.spec.HttpSessionImpl.getFilteredAttributeNames(HttpSessionImpl.java:140) > at io.undertow.servlet.spec.HttpSessionImpl.getAttributeNames(HttpSessionImpl.java:135) > at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:405) > at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:116) > ... 11 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7668) Revert unnecessary singleton subsystem schema 2.0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7668?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7668: --------------------------------- Summary: Revert unnecessary singleton subsystem schema 2.0 (was: Singleton subsystem downgrades in XML configuration file compared to initial state when configuration change is performed on server) > Revert unnecessary singleton subsystem schema 2.0 > ------------------------------------------------- > > Key: WFLY-7668 > URL: https://issues.jboss.org/browse/WFLY-7668 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Singleton subsystem downgrades after configuration change is performed on server: > {code} > 3a4 > > > 37a39,44 > > > > <system-properties> > > <property name="foo" value="bar"/> > > </system-properties> > > > > > 92a100 > > > 423c431 > < <subsystem xmlns="urn:jboss:domain:singleton:2.0"> > --- > > <subsystem xmlns="urn:jboss:domain:singleton:1.0"> > 473a482 > > > 487a497 > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7668) Revert singleton subsystem schema 2.0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7668?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7668: --------------------------------- Summary: Revert singleton subsystem schema 2.0 (was: Revert unnecessary singleton subsystem schema 2.0) > Revert singleton subsystem schema 2.0 > ------------------------------------- > > Key: WFLY-7668 > URL: https://issues.jboss.org/browse/WFLY-7668 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Singleton subsystem downgrades after configuration change is performed on server: > {code} > 3a4 > > > 37a39,44 > > > > <system-properties> > > <property name="foo" value="bar"/> > > </system-properties> > > > > > 92a100 > > > 423c431 > < <subsystem xmlns="urn:jboss:domain:singleton:2.0"> > --- > > <subsystem xmlns="urn:jboss:domain:singleton:1.0"> > 473a482 > > > 487a497 > > > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7671) Test DeploymentDescriptorTestCase Not Handling Own Clean Up

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7671: -------------------------------------- Summary: Test DeploymentDescriptorTestCase Not Handling Own Clean Up Key: WFLY-7671 URL: https://issues.jboss.org/browse/WFLY-7671 Project: WildFly Issue Type: Bug Components: Batch, Test Suite Reporter: Darran Lofthouse Assignee: James Perkins Fix For: 11.0.0.Alpha1 The test DeploymentDescriptorTestCase appears to be assuming it will only be run after 'mvn clean'. If I run the test manually I get the failure: - {noformat} Running org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.763 sec <<< FAILURE! - in org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase namedJdbcTest(org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase) Time elapsed: 0.127 sec <<< FAILURE! java.lang.AssertionError: expected:<1> but was:<6> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.testCompletion(DeploymentDescriptorTestCase.java:127) at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.namedJdbcTest(DeploymentDescriptorTestCase.java:115) {noformat} Next time I run it I get: - {noformat} Running org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.986 sec <<< FAILURE! - in org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase namedJdbcTest(org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase) Time elapsed: 0.129 sec <<< FAILURE! java.lang.AssertionError: expected:<1> but was:<7> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.testCompletion(DeploymentDescriptorTestCase.java:127) at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.namedJdbcTest(DeploymentDescriptorTestCase.java:115) {noformat} So the execution IDs are not getting set back to 0 before the test starts. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2044) Upgrade to JBoss Marshalling 2.0.0.Beta2

by Farah Juma (JIRA)

Farah Juma created WFCORE-2044: ---------------------------------- Summary: Upgrade to JBoss Marshalling 2.0.0.Beta2 Key: WFCORE-2044 URL: https://issues.jboss.org/browse/WFCORE-2044 Project: WildFly Core Issue Type: Component Upgrade Components: Server Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4561) Servlet Nonblocking I/O Suppressed InputStream Closed Error

by Mark S (JIRA)

[ https://issues.jboss.org/browse/WFLY-4561?page=com.atlassian.jira.plugin.... ] Mark S closed WFLY-4561. ------------------------ > Servlet Nonblocking I/O Suppressed InputStream Closed Error > ----------------------------------------------------------- > > Key: WFLY-4561 > URL: https://issues.jboss.org/browse/WFLY-4561 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Mark S > Assignee: Stuart Douglas > Attachments: AsyncIOServletTest.java > > > Created a Nonblocking I/O Servlet by following JEE Tutorial example here: > https://docs.oracle.com/javaee/7/tutorial/servlets013.htm > Due to my Eclipse Development Environment giving me the warning "Potential resource leak: 'input' may not be closed", I made a mistake by wrapping the following line with a try-with-resources statement. > {code} > final ServletInputStream input = request.getInputStream(); > {code} > Unfortunately, no exception was thrown to indicate that the connection was already closed before processing was attempted, where I believe there should have been. > -- > I have added the relevant source code to reproduce my situation. Please see attached code. > In the attached source, I added an AsyncListener to monitor the life cycle. > h4. Case 1 > Client Request: > {code} > curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo > {code} > The handleRequestAsPerJeeTutorialWithInputStreamIssue method will give the following output: > {code} > 2015-04-27 10:57:20,337 (INFO ) [] AsyncIOServletTest(37): doPost(..) > 2015-04-27 10:57:50,345 (INFO ) [] AsyncIOServletTest$1(55): onTimeout called: javax.servlet.AsyncEvent@24865a17 > 2015-04-27 10:57:50,359 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@54ff11f3 > {code} > Client Response: > {code} > <html><head><title>Error</title></head><body>Internal Server Error</body></html> > {code} > h4. Case 2 > Client Request: > {code} > curl -X POST -H "Content-Type: application/x-www-form-urlencoded" --data '{"records":[{"key":"key1","value":"SGVsbG8gV29ybGQ="}]}' "http://localhost:8080/webapp/test/test"; echo > {code} > The handleRequestAsPerJeeTutorial method will give the following output: > {code} > 2015-04-27 10:56:32,111 (INFO ) [] AsyncIOServletTest(37): doPost(..) > 2015-04-27 10:56:32,114 (INFO ) [] AsyncIOServletTest(84): handleRequestAsPerJeeTutorial(..) > 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(97): onDataAvailable() > 2015-04-27 10:56:32,121 (INFO ) [] AsyncIOServletTest$2(115): onAllDataRead() > 2015-04-27 10:56:32,125 (INFO ) [] AsyncIOServletTest$1(48): onComplete called: javax.servlet.AsyncEvent@3746c9ed > {code} > Client Response: > {code} > ...the response... > {code} > ---- > It is my opinion that a closed InputStream should cause an exception of some sort. And in this case at minimum, I think that the AsyncListener's onError should be called. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-793) Using @STRENGTH keyword in CipherSuiteSelector.fromString should cause descending sorting

by Ondrej Kotek (JIRA)

Ondrej Kotek created ELY-793: -------------------------------- Summary: Using @STRENGTH keyword in CipherSuiteSelector.fromString should cause descending sorting Key: ELY-793 URL: https://issues.jboss.org/browse/ELY-793 Project: WildFly Elytron Issue Type: Bug Components: SSL Affects Versions: 1.1.0.Beta14 Reporter: Ondrej Kotek Assignee: Darran Lofthouse Using {{@STRENGTH}} keyword in {{CipherSuiteSelector.fromString}} should cause descending sorting of cipher suites, like OpenSSL does, e.g. {{openssl ciphers -v 'ALL:!ADH:@STRENGTH'}}. There is comparator in {{SortByAlgorithmKeyLengthCipherSuiteSelector}} [1]. Or, am I wrong? Are cipher suites in {{javax.net.ssl.SSLParameters}} expected in ascending order? (Does it matter?) Will the OpenSSL provider expect ascending order? (Or will it parse cipher string itself?) The JavaDoc [2] should mention whether the sorting is ascending or descending. [1] https://github.com/wildfly-security/wildfly-elytron/blob/7666231fa76b95c3... [2] https://github.com/wildfly-security/wildfly-elytron/blob/7666231fa76b95c3... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-792) Allow security realms to associate a key with their realm identity instances

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-792?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-792: --------------------------- Description: * Kill off IL.principal completely * Add RI.getKey which returns a key that is specific to the realm instance * Add IL.key that, if present, is used to locate the identity; other fields in IL are checked against it and if there's a mismatch, an exception is thrown > Allow security realms to associate a key with their realm identity instances > ---------------------------------------------------------------------------- > > Key: ELY-792 > URL: https://issues.jboss.org/browse/ELY-792 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, Realms > Affects Versions: 1.1.0.Beta16 > Reporter: Pedro Igor > Assignee: Pedro Igor > > * Kill off IL.principal completely > * Add RI.getKey which returns a key that is specific to the realm instance > * Add IL.key that, if present, is used to locate the identity; other fields in IL are checked against it and if there's a mismatch, an exception is thrown -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-792) Allow security realms to associate a key with their realm identity instances

by Pedro Igor (JIRA)

Pedro Igor created ELY-792: ------------------------------ Summary: Allow security realms to associate a key with their realm identity instances Key: ELY-792 URL: https://issues.jboss.org/browse/ELY-792 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI, Realms Affects Versions: 1.1.0.Beta16 Reporter: Pedro Igor Assignee: Pedro Igor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2042) Improve query operation for nested child resources

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2042?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2042: ------------------------------------------ I believe this one would require bringing a wildcard notion into the filter, as most children have a dynamic element in their address and I expect filtering users, at least sometimes, would want to match against all the children of a particular type. That could be ok but we need to think through the semantics of where such a wildcard could be allowed and whether that can be done in a way that makes sense for all uses of 'filter'. > Improve query operation for nested child resources > -------------------------------------------------- > > Key: WFCORE-2042 > URL: https://issues.jboss.org/browse/WFCORE-2042 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Lin Gao > Assignee: Brian Stansberry > > This is another similar RFE as WFCORE-2041. > It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are +inside of nested child resources(not only by the first level of child resource)+, so that, for example, the following command can work well as expected: > {code:} > [standalone@localhost:9990 /] /subsystem=security:query(select=[security-domain], where={security-domain.authentication.login-modules.code=RealmDirect}) > { > "outcome" => "success", > "result" => undefined > } > // here the expected output are the security-domain resources which have the loging-module RealmDirect defined. > {code} > The {{security-domain.authentication.login-modules.code}} in 'where' parameter is proposed attribute name in enhanced syntax, other options maybe possible. > The different requirements between this WFCORE-2042 and WFCORE-2041 are: > * WFCORE-2041 focus on complex attributes in one management resource > * WFCORE-2042 focus on nested management resources with or without complex attributes -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2016