[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ]
Flavia Rainone commented on WFLY-4682:
--------------------------------------
[~mnovak] I downloaded the server, and when I remove the messaging-activemq subsystem, I get an error when starting the server:
{{08:15:50,503 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0009: Starting weld service for deployment simple-servlet.war
08:15:51,943 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."simple-servlet.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-servlet.war".WeldStartService: 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: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JMSContext with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @JMSConnectionFactory private SimpleServlet.context
at SimpleServlet.context(SimpleServlet.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
08:15:51,952 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "simple-servlet.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"simple-servlet.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"simple-servlet.war\".WeldStartService: Failed to start service
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JMSContext with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @JMSConnectionFactory private SimpleServlet.context
at SimpleServlet.context(SimpleServlet.java:0)
}}
> standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4682
> URL: https://issues.jboss.org/browse/WFLY-4682
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, MSC
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Bartosz Baranowski
> Labels: duplicate
> Attachments: standalone-full.xml
>
>
> Deployment (Servlet, EJB, MDB) which is using Websphere MQ 8 resource adapter to send/receive messages from external Websphere MQ 8 instance is not loading "javax.jms.api" module. Deployment is using JMS api.
> This is change in behaviour against previous versions EAP 6/Widlfly 9.
> There is no error during deploy. Failures occur in the moment when deployment for example servlet is called. Following error is logged in EAP 7.0.0.DR2 log:
> {code}
> 08:57:24,835 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "servlet.war" with deployment "servlet.war"
> 08:57:24,838 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /home/mnovak/projects/eap-tests-wsmq/ibm-mq-testsuite/src/test/config/ibm8/install/jboss-eap-7.0/standalone/data/content/62/931347d12b65c80cd2201372be52f0494e361a/content
> 08:57:25,794 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /CleaningServlet/CleaningServlet: java.lang.NoClassDefFoundError: javax/jms/Message
> at org.jboss.as.test.ibm.mq.servlet.CleaningServlet.doGet(CleaningServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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.ClassNotFoundException: javax.jms.Message from [Module "deployment.servlet.war:main" from Service Module Loader]
> 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)
> ... 30 more
> {code}
> Websphere MQ resource adapter is rar archive in deployments directory. It's not configured in module. Only way to force loading of "javax.jms.api" for deployment is to add Dependecies: javax.jms.api to MANIFEST.MF or add it to global-modules. This negatively affects usability.
> Can be javax.jms.api loaded for deployment by default for "full" and "full-ha" profile?
> I'm adding standalone-full.xml with configuration for EAP 7.0.0.DR2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ELY-415) Eliminate RuntimeExceptions thrown from SecurityRealm implementations.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-415:
------------------------------------
Summary: Eliminate RuntimeExceptions thrown from SecurityRealm implementations.
Key: ELY-415
URL: https://issues.jboss.org/browse/ELY-415
Project: WildFly Elytron
Issue Type: Task
Components: Realms
Reporter: Darran Lofthouse
Priority: Critical
Fix For: 1.1.0.CR1
Where a realm is temporarily unavailable we have the RealmUnavailableException - in other cases however our API generally requires that null or empty representations are returned when identities can not be loaded or validation.
In a few cases RuntimeExceptions have crept into the implementations, we need to eliminate these as any code written according the API and not expecting them risks breaking for unexpected RuntimeExceptions.
Each method on the API should also be double checked to ensure it clearly documents what should happen if it can not return the desired result.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JGRP-2010) RpcDispatcher/MessageDispatcher: don't copy the first anycast
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2010?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2010:
--------------------------------
When sending a message with an AnycastAddress, no copy is needed, either
> RpcDispatcher/MessageDispatcher: don't copy the first anycast
> -------------------------------------------------------------
>
> Key: JGRP-2010
> URL: https://issues.jboss.org/browse/JGRP-2010
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> If we have an anycast to targets B,C,D, this will be sent as 3 unicasts: to A, to B and to C. The original message is copied for each of the 3 target dests (only the headers are copied, not the payload). The copy is needed to prevent protocols from changing the (same) headers when the message is sent (or retransmitted).
> As an optimization, we don't need to copy the *first* message; in the above example, we need to copy only B and C.
> For anycasts to single destination, we don't need to copy anything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JGRP-2010) RpcDispatcher/MessageDispatcher: don't copy the first anycast
by Bela Ban (JIRA)
Bela Ban created JGRP-2010:
------------------------------
Summary: RpcDispatcher/MessageDispatcher: don't copy the first anycast
Key: JGRP-2010
URL: https://issues.jboss.org/browse/JGRP-2010
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.6.8, 4.0
If we have an anycast to targets B,C,D, this will be sent as 3 unicasts: to A, to B and to C. The original message is copied for each of the 3 target dests (only the headers are copied, not the payload). The copy is needed to prevent protocols from changing the (same) headers when the message is sent (or retransmitted).
As an optimization, we don't need to copy the *first* message; in the above example, we need to copy only B and C.
For anycasts to single destination, we don't need to copy anything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-5715) Wildfly 9/10 removing deployments after a certain time
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-5715?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet commented on WFLY-5715:
-----------------------------------------
[~oleg.hoefling] Is there a way for you to connect to hipchat / irc for easier exchange ? Also could you attach your log files to https://issues.jboss.org/browse/WFCORE-1330 as this bug entry is closed.
> Wildfly 9/10 removing deployments after a certain time
> ------------------------------------------------------
>
> Key: WFLY-5715
> URL: https://issues.jboss.org/browse/WFLY-5715
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final, 10.0.0.CR4
> Environment: Ubuntu 12.04.5 LTS
> Reporter: Sven Ulrich
> Assignee: ehsavoie Hugonnet
> Attachments: Dummy.war, ifxjdbc_4.10.jar, server.log, standalone.xml
>
>
> I have setup a Wildfly 10 CR4 on a Ubuntu 12.04.5 LTS. The server is running fine.
> Now I want to deploye my jar files (jdbc driver and jee apps).
> All is uploaded via the management web interface running on the port 10010 (added offset of 20 because a WF8 is running on Port 8080)
> First I log into the web interface and navigate to the tab deployments. Then I use the button add.
> In the popup window:
> 1: Upload a new deployment
> 2: I choose ifxjdbc_4.10.jar for e.g.
> 3: In Verify upload enabled is set and everything else is standard
> 4: The upload takes round about 30sec.
> Now I can setup datasources for this driver and its works fine. My next step is to stop the server and restart it. Then the server wont start because the content is missing for the jar.
> It wont be an issue for me if i could be 100% sure that the server wont be restarted anytime :)
> I have added my standalone.xml and the log with hopefully all needed information.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1313) User with slash or backslash char in LDAP name cannot log in through security-realm
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1313?page=com.atlassian.jira.plugi... ]
Lin Gao reassigned WFCORE-1313:
-------------------------------
Assignee: Lin Gao (was: Darran Lofthouse)
> User with slash or backslash char in LDAP name cannot log in through security-realm
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-1313
> URL: https://issues.jboss.org/browse/WFCORE-1313
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Lin Gao
> Attachments: users.ldif
>
>
> According to LDAP specification [1], DN can contain slash char without escaping or escaped backslash, etc.
> I am not able to log in to management console with username "Slash/Char" or "Back\Slash". But I would be able to log in there.
> I can see this in Wireshark
> *Slash/Char*
> {code}
> LDAPMessage bindRequest(1) ""uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple
> LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : "uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x22 0x75 0x69 0x64 0x3D 0x53 0x6C 0x61 0x73 0x68 0x2F 0x43 0x68 0x61 0x72 0x2
> {code}
> You can see there quotation marks around *uid=Slash/Char*.
> *Back\Slash*
> {code}
> LDAPMessage bindRequest(1) "uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple
> LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x75 0x69 0x64 0x3D 0x42 0x61 0x63 0x6B 0x5C 0x5C 0x5C 0x53 0x6C 0x61 0x73 0x6
> {code}
> You can see there three backslash chars.
> In my opinion problem can be somewhere around this
> {code}
> javax.naming.NameImpl.stringifyComp(String comp)
> {code}
> [1] https://tools.ietf.org/html/rfc2253#section-3
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-1343) Memory leak in host controller
by Aparna Chaudhary (JIRA)
Aparna Chaudhary created WFCORE-1343:
----------------------------------------
Summary: Memory leak in host controller
Key: WFCORE-1343
URL: https://issues.jboss.org/browse/WFCORE-1343
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Final
Reporter: Aparna Chaudhary
Assignee: Brian Stansberry
Priority: Critical
Attachments: WFCORE-992-HC-Leak.PNG
The ManagedServerProxy class in host-controller contains a memory leak. The leak can be reproduced by performing multiple requests to HTTP management API.
{noformat}
http://<host>:9990/management/host/host0/server/server0/core-service/platform-mbean/type/memory?include-runtime=true
{noformat}
Applying the fix proposed in WFCORE-992 solves the leak.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ]
Thomas Diesler reassigned WFLY-6096:
------------------------------------
Assignee: Paul Ferraro (was: Thomas Diesler)
> ISPN-5876 changes need to be configurable
> -----------------------------------------
>
> Key: WFLY-6096
> URL: https://issues.jboss.org/browse/WFLY-6096
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Stephen Fikes
> Assignee: Paul Ferraro
>
> When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
> For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
> As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
> Though the second case _may_ be the more common, it seems like the default should be to not reduce the integrity guarantee.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header
by Tobias Lehr (JIRA)
[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ]
Tobias Lehr commented on WFLY-6097:
-----------------------------------
out integrationtests confirm this bug.
> Error response handling from bean validation ignores Accept header
> ------------------------------------------------------------------
>
> Key: WFLY-6097
> URL: https://issues.jboss.org/browse/WFLY-6097
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Mac OS X El Captain
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Renann Prado
> Assignee: Jason Greene
> Attachments: delivery-optimization-ear-1.0.Final.ear
>
>
> Basically I have a very simple application that has request validation in the REST endpoints.
> According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request.
> https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati...
> The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't.
> I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final.
> In WF 9.0.2.Final I used to get the below error *JSON*
> {code:json}
> {
> "exception": null,
> "fieldViolations": [],
> "propertyViolations": [],
> "classViolations": [],
> "parameterViolations": [{
> "constraintType": "PARAMETER",
> "path": "registerLogisticsNetwork.arg0.name",
> "message": "may not be null",
> "value": ""
> }],
> "returnValueViolations": []
> }
> {code}
> In WF 10.0.0.Final I get this:
> {code}
> [PARAMETER]
> [registerLogisticsNetwork.arg0.name]
> [may not be null]
> []
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ]
Richard Janík edited comment on WFLY-5932 at 2/1/16 2:40 AM:
-------------------------------------------------------------
Hi Stuart,
first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately.
Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again.
(I'm detailing the process in case you have something to say about it)
What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems?
tl;dr
I don't think commit 394c7b8 fixes the issue - I'm still seeing it.
edit:
After discussion with Stuart, I've realized that the process above is unnecessarily complicated. Still, sso-fix branch doesn't seem to fix the issue.
was (Author: rjanik):
Hi Stuart,
first, I created a branch of the 1.3.12.Final Undertow tag (which is the version of Undertow in current Wildfly master) and cherry-picked the last commit of sso-fix branch (394c7b8). I rebuilt Undertow, which replaced 1.3.12.Final in my local repository and then I rebuilt Wildfly with this spoofed dependency. I verified (by decompilation) that the commit is in there and then run my reproducer, which failed, unfortunately.
Second, I rebuilt Undertow from the sso-fix branch, where I just changed versions to 1.3.12.Final (again, to spoof the dependency for Wildfly), then I rebuilt Wildfly (branch master, last commit 4ca733c), verified modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.12.Final.jar contains the fix from last commit of sso-fix branch. Then I run my reproducer, which failed again.
(I'm detailing the process in case you have something to say about it)
What reproducer are you using? If you're using the reproducer from WFLY-5473, which step causes problems?
tl;dr
I don't think commit 394c7b8 fixes the issue - I'm still seeing it.
> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5932
> URL: https://issues.jboss.org/browse/WFLY-5932
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months