[
https://issues.apache.org/jira/browse/TOMEE-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bauke Scholtz updated TOMEE-4631:
---------------------------------
Description:
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:java}
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/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}
was:
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}
> 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
> Priority: Major
>
> 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:java}
> 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/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)
