[
https://issues.jboss.org/browse/WFLY-9240?page=com.atlassian.jira.plugin....
]
Martin Kouba commented on WFLY-9240:
------------------------------------
[~dlofthouse] Actually, this is the same output. Security domain is null and so Weld
integration code is using the default NOOP impl which does not associate the security
context with the thread where an asynchronous event is delivered:
https://github.com/weld/wildfly/blob/11.0.0.Beta1-weld3/weld/subsystem/sr...
Note that when delivering an asynchronous event a dedicated Weld thread pool is used and
TCCL is not supposed to be set there.
However, the security domain should be available when we "capture" the security
context. At least it was available in 11.0.0.Alpha1.
WeldSecurityServices not able to obtain the current SecurityDomain
anymore
--------------------------------------------------------------------------
Key: WFLY-9240
URL:
https://issues.jboss.org/browse/WFLY-9240
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Security
Affects Versions: 11.0.0.Beta1, 11.0.0.CR1
Reporter: Martin Kouba
Assignee: Darran Lofthouse
Priority: Critical
The integration code used by Weld 3 to propagate the security context of the current
thread to different threads (needed for async events CDI 2.0 feature) is not able to
obtain the current {{org.wildfly.security.auth.server.SecurityDomain}} anymore.
The invocation of
[
SecurityDomain.getCurrent()|https://github.com/weld/wildfly/blob/11.0.0.B...]
returns {{null}}.
Note that this worked on WildFly *11.0.0.Alpha1*.
It's also possible that the test (see also steps to reproduce) is wrong. A
review/help from a security expert would be appreciated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)