Bauke Scholtz created TOMEE-4631:
------------------------------------
Summary: arquillian-tomee-remote: static "registered" latch breaks
container re-registration on a second Arquillian Manager (e.g. failsafe
rerunFailingTestsCount)
Key: TOMEE-4631
URL: https://issues.apache.org/jira/browse/TOMEE-4631
Project: TomEE
Issue Type: Bug
Components: TomEE Arquillian Adapters
Reporter: Bauke Scholtz
h3. Affected
{{arquillian-tomee-remote}} 10.1.5 and 11.0.0-M1 ({{RemoteTomEEExtension}} is
identical in both — the latch is still present on the latest release).
h3. Summary
When a second Arquillian {{Manager}} is bootstrapped within the same JVM fork,
{{arquillian-tomee-remote}} fails to register its {{DeployableContainer}}, and
every deployment then fails validation with:
{code}
org.jboss.arquillian.container.test.impl.client.deployment.ValidationException:
DeploymentScenario contains a target (_DEFAULT_) not matching any defined
Container in the registry.
Please include at least 1 Deployable Container on your Classpath.
{code}
The most common trigger is maven-failsafe-plugin's {{rerunFailingTestsCount}}:
the first run registers the container fine, but the rerun of a failed test — a
new {{Manager}} in the same JVM — gets an empty {{ContainerRegistry}}. A
feature meant to mask flaky tests instead turns every recoverable flake into a
hard, misleading failure on TomEE specifically.
h3. Root cause
{{RemoteTomEEExtension.register()}} guards container registration behind a
*JVM-static* flag:
{code:java}
private static final AtomicBoolean registered = new AtomicBoolean(false);
...
if (!registered.getAndSet(true)) {
builder.observer(...);
builder.service(DeployableContainer.class, RemoteTomEEContainer.class)
.service(...);
}
{code}
{{register()}} runs once per {{Manager}} bootstrap. The first bootstrap
registers the container and flips the static flag. The second bootstrap in the
same JVM finds the flag already {{true}} and *skips*
{{builder.service(DeployableContainer.class, ...)}}, leaving that Manager's
registry empty -> {{_DEFAULT_}} target matches no container.
Because the latch is {{static}}, registration is not idempotent across
independent Manager lifecycles in one JVM. The sibling
{{EmbeddedTomEEExtension}} has no such latch and registers unconditionally —
which is why {{arquillian-tomee-embedded}} and every other Arquillian container
adapter survive a rerun, and only {{arquillian-tomee-remote}} does not.
h3. Reproduction
# Any Arquillian test using {{arquillian-tomee-remote}}.
# Configure maven-failsafe-plugin with {{-Dfailsafe.rerunFailingTestsCount=2}}.
# Make a test fail once (a real flake or a forced assertion).
# The rerun ({{Run 1}}/{{Run 2}}) throws the {{ValidationException}} above
instead of re-running against the still-running container.
h3. Evidence (OmniFaces CI, tomee-myfaces profile)
Same job, {{mvn -B verify -P tomee-myfaces
-Dfailsafe.rerunFailingTestsCount=2}}. A test flakes once, then both reruns
throw the {{_DEFAULT_}} ValidationException and the job goes red:
*
https://github.com/omnifaces/omnifaces/actions/runs/28445054604/job/84292140352
*
https://github.com/omnifaces/omnifaces/actions/runs/28387525716/job/84107967437
*
https://github.com/omnifaces/omnifaces/actions/runs/26466956637/job/77929735464
*
https://github.com/omnifaces/omnifaces/actions/runs/26462946191/job/77915469439
*
https://github.com/omnifaces/omnifaces/actions/runs/26462539293/job/77913997807
Contrast — the *same class* of timing flake on every other Arquillian-based
server reruns cleanly ({{Run 2: PASS}}, job green), because those adapters
re-register their container:
* GlassFish:
https://github.com/omnifaces/omnifaces/actions/runs/28445069053/job/84292192030
({{InputFileIT.uploadSingle}} Run 1 flake -> Run 2 PASS)
* Payara:
https://github.com/omnifaces/omnifaces/actions/runs/28398701494/job/84144088156
({{ValidateUniqueIT.testForm1}} Run 1 flake -> Run 2 PASS)
* WildFly:
https://github.com/omnifaces/omnifaces/actions/runs/28382546433/job/84088673758
({{SocketIT.test}} Run 1 flake -> Run 2 PASS)
h3. Expected
A second {{Manager}} in the same JVM should get the {{DeployableContainer}}
registered again, so reruns work as they do for every other adapter.
h3. Suggested fix
Drop the JVM-static latch and register unconditionally, matching
{{EmbeddedTomEEExtension}}. The {{getAndSet}} guard appears to be a workaround
for a double-registration {{IllegalArgumentException}}; if double-registration
within a _single_ builder is the concern, scope the guard to the
builder/Manager rather than a {{static}} field — a JVM-global latch
over-corrects and breaks the legitimate multi-Manager case.
----
{color:#888888}Generated by Claude Code (https://claude.com/claude-code){color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
