[
https://issues.apache.org/jira/browse/TOMEE-4655?focusedWorklogId=1031928&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031928
]
ASF GitHub Bot logged work on TOMEE-4655:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jul/26 19:24
Start Date: 23/Jul/26 19:24
Worklog Time Spent: 10m
Work Description: jungm opened a new pull request, #2850:
URL: https://github.com/apache/tomee/pull/2850
## What
Fixes [TOMEE-4655](https://issues.apache.org/jira/browse/TOMEE-4655): a
failed CDI/EJB deployment leaks its deployment id into later apps.
## Why
`Assembler.createApplication(AppInfo, ClassLoader, boolean)` registers every
EJB's deployment id in the `ContainerSystem` (via `initEjbs`) **before** it
starts CDI. Its `catch` block treated two exception types specially:
```java
} catch (final ValidationException | DeploymentException ve) {
throw ve; // no cleanup
} catch (final Throwable t) {
destroyApplication(appInfo); // cleanup
...
}
```
CDI startup failures bubble up as
`jakarta.enterprise.inject.spi.DeploymentException`, so they hit the first
clause and returned **without** undeploying the partially deployed application.
Every `BeanContext` registered before the CDI phase stayed in
`CoreContainerSystem.deployments`. The next app reusing one of those ids then
tripped `getDuplicates` → `DuplicateDeploymentIdException` before any of its
own lifecycle/managed-bean/concurrency checks ran — turning one bad deployment
into a cascade of unrelated failures.
The git history shows that clause was only ever added so these two exception
types wouldn't be wrapped in an `OpenEJBException` (commit `51ab12b2`, *"as
ValidationException, DeploymentException shouldn't be wrapped"*). Losing the
rollback was an accidental side effect, not the intent.
## The fix
Run `destroyApplication(appInfo)` on this path as well, then rethrow the
original exception unchanged — preserving the "don't wrap" intent while
releasing the ids.
## Testing
New `FailedDeploymentIdCleanupTest` deploys an app whose singleton has an
unsatisfiable `@Inject` (failing at CDI start), then asserts a second app can
reuse the same deployment id. Verified it has real diagnostic power:
- **Without the fix:** `AssertionError: the failed deployment leaked its
deployment id expected null, but was:<BeanContext(id=TheSharedDeploymentId)>`
- **With the fix:** passes
- No regressions across the neighbouring `assembler.classic` tests
(`RedeployTest`, `EjbRefTest`, etc.)
Also verified end-to-end against the Jakarta EE 11 Web Profile TCK
(`enterprise-beans-30` partition, Plume): **1138 tests, 0 failures, 0 errors**,
and zero `DuplicateDeploymentIdException`. The four excluded test patterns the
ticket calls out now deploy cleanly.
## Note for reviewers
The matching TCK-harness changes (removing the exclusions, updating the
expected class count, and `KNOWN_FAILURES.md`) live in the separate
`apache/tomee-tck` repo and will be submitted there. Two
`JsfClientEjblitejsfTest` classes among those exclusions still fail after this
fix, but for an unrelated, already-documented reason — the OpenWebBeans "cannot
proxy a final method" interceptor gap, which the deployment-id leak had been
masking. They are moved into that existing exclusion block rather than left
enabled.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1031928)
Remaining Estimate: 0h
Time Spent: 10m
> A failed CDI/EJB deployment leaks its deployment ID into later apps
> -------------------------------------------------------------------
>
> Key: TOMEE-4655
> URL: https://issues.apache.org/jira/browse/TOMEE-4655
> Project: TomEE
> Issue Type: Bug
> Reporter: Markus Jung
> Assignee: Markus Jung
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a CDI or EJB deployment fails, TomEE does not clean up the deployment ID
> it registered for that app. The stale ID stays registered, so the next app
> that reuses it fails with {{DuplicateDeploymentIdException}} before its own
> lifecycle, managed-bean, or concurrency checks even run.
> This turns one bad deployment into a cascade of unrelated test failures in
> whichever app deploys next with a matching ID.
> h2. Steps to reproduce / TCK reference
> Excluded in {{runner-webprofile/exclusions/enterprise-beans-30.txt}} in the
> apache/tomee-tck harness repo:
> * {{**/interceptor/singleton/lifecycle/descriptor/*Test.java}}
> * {{**/packaging/war/mbean/interceptor/lifecycleejbcdi/*Test.java}}
> * {{**/singleton/concurrency/container/annotated/*Test.java}}
> * {{**/singleton/concurrency/container/inheritance/*Test.java}}
> Once fixed, remove the matching lines and confirm a deployment that follows a
> failed one with the same ID no longer fails with
> {{DuplicateDeploymentIdException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
