What

Fixes 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:

} 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