[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-5418:
------------------------------
Summary: start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode (was: start-delivery/stop-delivery operations are missing from MDB deployment in domain mode)
> start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-5418
> URL: https://issues.jboss.org/browse/WFLY-5418
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: JBoss AS7 7.2.0.Final
> Environment: JBoss EAP 6.4.3
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
>
> It is possible to start/stop delivery of messages to MDB in standalone mode using operations
> start-delivery() and stop-delivery() on MDB deployment.
> Those operations are missing from MDB deployment in domain mode
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5400) Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.... ]
Miroslav Novak reassigned WFLY-5400:
------------------------------------
Assignee: ANGELA ROBERTSON (was: Deon Ballard)
> Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
> ------------------------------------------------------------------------------------
>
> Key: WFLY-5400
> URL: https://issues.jboss.org/browse/WFLY-5400
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, JMS
> Affects Versions: 10.0.0.CR1
> Reporter: Miroslav Novak
> Assignee: ANGELA ROBERTSON
> Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml
>
>
> Failover of standalone JMS client fails if netty (blocking/non-blocking) connector is used. There are 2 EAP 7.0.0.DR10 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed then backup activates but client does not failover to it:
> {code}
> ent message with property count: 110867, messageId:ID:20310150-62a0-11e5-ada8-b3332c72af23
> Sent message with property count: 110868, messageId:ID:20310151-62a0-11e5-ada8-b3332c72af23
> Sep 24, 2015 11:39:27 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:40 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:55 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:40:10 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> {code}
> Attaching live/backup configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5423) Some tests don't remove modules properly
by Jan Tymel (JIRA)
Jan Tymel created WFLY-5423:
-------------------------------
Summary: Some tests don't remove modules properly
Key: WFLY-5423
URL: https://issues.jboss.org/browse/WFLY-5423
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 10.0.0.CR2
Reporter: Jan Tymel
Some test cases (e.g. org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase) don't remove their test modules properly. If the jboss.dist property is used and such a test is run, there will remain redundant folders in JBOSS_DIST/modules.
E.g. if the ExternalTagLibTestCase is executed, the folder "test" will remain in "modules" folder of JBOSS_DIST.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5416) Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5416?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5416:
--------------------------------------
This looks good to me
> Unhandled exceptions from custom JASPI modules should cause the HTTP status code to be set as an error (500, 400, etc)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5416
> URL: https://issues.jboss.org/browse/WFLY-5416
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Derek Horton
> Assignee: Stuart Douglas
>
> If a custom JASPI auth module throws an exception, Wildfly/Undertow (the JASPI authenticator) ignores it and returns a 200. The web page that was requested does not get displayed. A blank page and a HTTP 200 are returned.
> Should a 40x or a 500 be returned instead? Or is it the responsibility of the custom JASPI auth module to set the status correctly?
> It seems like the container would need to be careful and not overwrite a status code that the JASPI module had explicitly set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5422) SSO is not destroyed after session timeout period of <distributable/> app.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5422?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-5422:
------------------------------------
Steps to Reproduce:
1. 2 same FORM authenticated based app. Session timeout set to 1 min. Application marked <distributalble/> in web.xml
2. SSO switched on in undertow subsystem in standalone.xml using <single-sign-on path="/" />
3. Access first application - login/password requested as expected. Login succesfull.
4. I can access second deployed application as well. - SSO works as expected.
5. Wait > 1 min
6a. Non-<distributalble/> application
Accessing first and second application requires login
Active session count= 0. [1]
6b. <distributalble/> application
Accessing first and second application doesnt require login
Active session count= 1. [2]
was:
1. 2 same FORM authenticated based app. Session timeout set to 1 min. Application marked <distributalble/> in web.xml
2. SSO switched on in undertow subsystem in standalone.xml using <single-sign-on path="/" />
3. Access first application - login/password requested as expected. Login succesfull.
4. I can access second deployed application as well. - SSO works as expected.
5. Wait > 1 min
6a. Non-<distributalble/> application
Accessing first and second application requires login
Active session count= 0. [1]
6b. <distributalble/> application
Accessing first and second application doesnt require login
Active session count= 1. [2]
Assignee: Paul Ferraro (was: Stuart Douglas)
The root cause if this is that the clustering subsystem does not implement the Undertow SessionManager contract correctly. In particular on timeout it just directly invokes the servlet HttpSessionListener implementations, but ignores any Undertow SessionListener implementations that are registered with DistributableSessionManager. As the SSO impl uses these listeners the SSO session never expires.
> SSO is not destroyed after session timeout period of <distributable/> app.
> --------------------------------------------------------------------------
>
> Key: WFLY-5422
> URL: https://issues.jboss.org/browse/WFLY-5422
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Security
> Affects Versions: 10.0.0.CR2
> Reporter: Martin Choma
> Assignee: Paul Ferraro
> Priority: Critical
>
> Using <distributable/> application cause SSO doesnt destroy after session timeout period. Base on [1], there is still active session, what is probably cause that SSO is not destroyed.
> Setting similar in EAP6 requires user to login after session timeout period.
> Setting priority to critical because of regression with security impacts.
> [1]
> [standalone@localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
> "outcome" => "success",
> "result" => 0
> }
> [2]
> [standalone@localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
> "outcome" => "success",
> "result" => 1
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5100) Server does not start when transaction subsystem configures journal object store
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-5100?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-5100:
---------------------------------
Hi Ondra,
The narayana version has upgrade to 5.2.5.Final. I check on my machine that it works now. can you confirm that the issue resolved ?
> Server does not start when transaction subsystem configures journal object store
> --------------------------------------------------------------------------------
>
> Key: WFLY-5100
> URL: https://issues.jboss.org/browse/WFLY-5100
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.Beta1, 10.0.0.Beta2, 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Priority: Blocker
> Fix For: 10.0.0.Final
>
> Attachments: standalone.xml
>
>
> Currently when object store is configured to use journal to save the txn log the server won't start.
> For WFLY 10.Beta1 there is trouble of attributes naming - see WFLY-5078. But either when used old naming [1] (hornetq instead of activemq) the server fails to start [2].
> For WFLY 10.CR1 the naming works fine and {{use-journal-store}} works when used via jboss-cli.sh but the server starts still with the errors.
> [1]
> {code}
> /subsystem=transactions:write-attribute(name=use-journal-store, value=true)
> {code}
> [2]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012135: Could not create Store type: com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:155)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.getActionStore(StoreManager.java:110)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.getRecoveryStore(StoreManager.java:67)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.<init>(CommitMarkableResourceRecordRecoveryModule.java:156)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at java.lang.Class.newInstance(Class.java:442)
> at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:135)
> at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:192)
> at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:444)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:865)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:107)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:477)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:132)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:112)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:119)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> Caused by: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/core/journal/SequentialFileFactory
> at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.<init>(HornetqObjectStoreAdaptor.java:78)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at java.lang.Class.newInstance(Class.java:442)
> at com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:135)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:151)
> ... 24 more
> Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.journal.SequentialFileFactory from [Module "org.jboss.jts:main" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 32 more
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaRecoveryManager" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
> Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012135: Could not create Store type: com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor
> Caused by: java.lang.NoClassDefFoundError: org/apache/activemq/artemis/core/journal/SequentialFileFactory
> Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.journal.SequentialFileFactory from [Module \"org.jboss.jts:main\" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR8/modules/system/layers/base))]"}}
> INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: Failed to start service
> {code}
> The reason is explained in comment
> https://issues.jboss.org/browse/WFLY-5078?focusedCommentId=13098047#comme...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (DROOLS-929) kie-server POST fails with No resource method found for POST, return 405 with Allow header
by Stefano Picozzi (JIRA)
Stefano Picozzi created DROOLS-929:
--------------------------------------
Summary: kie-server POST fails with No resource method found for POST, return 405 with Allow header
Key: DROOLS-929
URL: https://issues.jboss.org/browse/DROOLS-929
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.3.0.Final
Reporter: Stefano Picozzi
Assignee: Edson Tirelli
Priority: Blocker
Testing the kie-server 6.3.0.FINAL build. I did this by pulling down the jboss/kie-server-showcase docker image and replacing the deployments directory with the kie-server.war for the 6.3.0.FINAL release. My tests showed that the REST API works for GET request for inspecting the decision server, works for PUT requests for creating a container but fails when trying to POST facts against the container. Error returned is as per wildfly log fragment below:
...
01:45:48,333 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "kie-server.war" (runtime-name : "kie-server.war")
01:45:48,354 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
01:45:48,354 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
01:45:48,355 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 11713ms - Started 407 of 458 services (105 services are lazy, passive or on-demand)
01:46:42,788 WARN [org.kie.scanner.embedder.MavenSettings] (default task-4) Environment variable M2_HOME is not set
01:46:43,310 INFO [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
01:46:46,462 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (default task-4) KieModule was added: ZipKieModule[releaseId=com.redhat.demos:weightwatchers:1.0,file=/opt/jboss/.m2/repository/com/redhat/demos/weightwatchers/1.0/weightwatchers-1.0.jar]
01:46:46,699 INFO [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
01:46:47,010 INFO [org.kie.server.services.impl.KieServerImpl] (default task-4) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
01:47:12,411 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-6) failed to execute: javax.ws.rs.NotAllowedException: No resource method found for POST, return 405 with Allow header
at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:375) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_85]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_85]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFLY-5422) SSO is not destroyed after session timeout period of <distributable/> app.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5422?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-547 to WFLY-5422:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-5422 (was: UNDERTOW-547)
Component/s: Clustering
Security
(was: Security)
Affects Version/s: 10.0.0.CR2
(was: 1.3.0.CR1)
> SSO is not destroyed after session timeout period of <distributable/> app.
> --------------------------------------------------------------------------
>
> Key: WFLY-5422
> URL: https://issues.jboss.org/browse/WFLY-5422
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Security
> Affects Versions: 10.0.0.CR2
> Reporter: Martin Choma
> Assignee: Stuart Douglas
> Priority: Critical
>
> Using <distributable/> application cause SSO doesnt destroy after session timeout period. Base on [1], there is still active session, what is probably cause that SSO is not destroyed.
> Setting similar in EAP6 requires user to login after session timeout period.
> Setting priority to critical because of regression with security impacts.
> [1]
> [standalone@localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
> "outcome" => "success",
> "result" => 0
> }
> [2]
> [standalone@localhost:9990 /] /deployment=secured-webapp.war/subsystem=undertow:read-attribute(name=active-sessions)
> {
> "outcome" => "success",
> "result" => 1
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months