Back to bug 1005093

Who When What Removed Added
Jaikiran Pai 2013-09-06 08:23:56 UTC Status NEW ASSIGNED
John Doyle 2013-09-06 13:48:35 UTC CC jdoyle
Derek Horton 2013-09-06 20:00:11 UTC CC dehort
Brian Stansberry 2013-09-08 16:33:57 UTC Status ASSIGNED MODIFIED
Target Release --- EAP 6.2.0
CC brian.stansberry
Target Milestone --- Pending
Paul Gier 2013-09-17 20:18:30 UTC Status MODIFIED ON_QA
Target Milestone Pending ER1
Jan Martiska 2013-09-19 12:01:33 UTC Status ON_QA VERIFIED
Brian Stansberry 2013-10-07 15:36:07 UTC CC brian.stansberry
John Skeoch 2013-10-23 23:03:09 UTC CC dimitris
John Skeoch 2013-10-23 23:05:17 UTC Assignee jpai dimitris
Dimitris Andreadis 2013-10-24 18:27:01 UTC Assignee dimitris david.lloyd
Dana Mison 2013-11-28 07:38:23 UTC CC wfink
CC dmison
Doc Text An EJB that is called asynchronously from a servlet can potentially lose it’s security context if the servlet invocation completes first. This occurred when security context of the servlet was cleared because both the servlet and the EJB threads share the same SecurityContext instance. Now the SecurityContext attributes are copied from the instance on the servlet thread to a new instance of the SecurityContext object on the EJB thread. Updates to SecurityContext instances on one thread no longer affect instances on other threads as expected.
Dana Mison 2013-12-04 05:11:06 UTC Doc Text An EJB that is called asynchronously from a servlet can potentially lose it’s security context if the servlet invocation completes first. This occurred when security context of the servlet was cleared because both the servlet and the EJB threads share the same SecurityContext instance. Now the SecurityContext attributes are copied from the instance on the servlet thread to a new instance of the SecurityContext object on the EJB thread. Updates to SecurityContext instances on one thread no longer affect instances on other threads as expected. An EJB that is called asynchronously from a servlet can potentially lose its security context if the servlet invocation completes first. This occurred when security context of the servlet was cleared because both the servlet and the EJB threads share the same SecurityContext instance. Now the SecurityContext attributes are copied from the instance on the servlet thread to a new instance of the SecurityContext object on the EJB thread. Updates to SecurityContext instances on one thread no longer affect instances on other threads as expected.
mark yarborough 2013-12-15 16:21:03 UTC Status VERIFIED CLOSED
Resolution --- CURRENTRELEASE
Last Closed 2013-12-15 11:21:03 UTC
Dana Mison 2014-05-27 01:28:03 UTC CC dmison

Back to bug 1005093