[
https://issues.jboss.org/browse/WFLY-10134?page=com.atlassian.jira.plugin...
]
Brian Stansberry commented on WFLY-10134:
-----------------------------------------
[~dmlloyd] Perhaps this non-extension module (i.e. kernel depends on it):
https://github.com/wildfly/wildfly-core/blame/master/core-feature-pack/sr...
which leads to this:
https://github.com/wildfly/wildfly-core/blame/master/core-feature-pack/sr...
This is nothing new though. And it doesn't match your traces, since ServerService
Thread Pool shouldn't be loading the kernel-dependency modules, and the undertow
extension wouldn't be in the mix. OTOH I don't see why this wouldn't have
been a problem long ago, unless JBoss Modules defers loading optional=true modules
until....<draws a blank/>.
ee8.preview.mode property is racy
---------------------------------
Key: WFLY-10134
URL:
https://issues.jboss.org/browse/WFLY-10134
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: David Lloyd
Priority: Critical
The {{ee8-temp}} tests set the {{ee8.preview.mode}} property in the server management
model, relying on system properties to get parsed and set before extensions which use Java
EE 8 APIs are loaded. This assumption appears to be invalid.
System properties are installed by the boot controller thread, and extensions are loaded
in server service threads. In testing with the latest jboss-modules, I've observed
cases where the controller thread does not add system properties until after some
extension loading has happened in the server service threads. I haven't untangled why
this happens only with the most recent jboss-modules in play, but the race exists
regardless.
Setting the {{ee8.preview.mode}} in {{arquillian.xml}} appears to work around the issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)