[
https://issues.apache.org/jira/browse/TOMEE-4655?focusedWorklogId=1032353&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1032353
]
ASF GitHub Bot logged work on TOMEE-4655:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 27/Jul/26 08:13
Start Date: 27/Jul/26 08:13
Worklog Time Spent: 10m
Work Description: rzo1 commented on PR #2850:
URL: https://github.com/apache/tomee/pull/2850#issuecomment-5088904524
Correct diagnosis and the minimal fix. Confirmed the chain: the unwrapped
`DeploymentException` really does come from
`ThreadSingletonServiceImpl:259`, `initEjbs`
really does register ids before `new CdiBuilder().build(...)`, and the
message key
`createApplication.undeployFailed` already exists at
`Messages.properties:76`. Ran the
test both ways — unpatched it fails with
`the failed deployment leaked its deployment id expected null, but
was:<BeanContext(id=TheSharedDeploymentId)>`.
One thing I'd like fixed before merge, which my local run surfaced:
- Rolling back a failure that happens *before* `startEjbs` now drives
`Container.stop/undeploy` over `BeanContext`s that were never deployed
into their
container, which emits ERROR-level NPEs (e.g.
`SingletonInstanceManager:216`) for every
singleton/stateful bean. Since a CDI bootstrap failure is now the most
common path
through this branch, that means the common failure mode gets a wall of
ERROR-level
noise stacked on top of the real cause. Guarding `destroyApplication` on
whether
`startEjbs` ran, or making the container stop tolerant of an undeployed
BeanContext,
would fix it.
And one I couldn't prove but would want smoke-tested:
- For webapps, `destroyApplication` calls
`webAppBuilder.undeployWebApps(appInfo)`, which
ends in `host.removeChild(standardContext)`
(`TomcatWebAppBuilder:1663-1690`), plus
`ClassLoaderUtil.destroyClassLoader`. `createApplication` for a webapp
runs on the
Tomcat context-start thread, and `TomcatWebAppBuilder`'s own catch at
:1341 then calls
`undeploy(...)` again. So this newly routes the most common webapp
deployment failure
into an in-flight Catalina child removal plus classloader destruction,
followed by a
second undeploy from the caller.
The pre-existing `catch (Throwable)` branch already does exactly this for
other
failures and the second undeploy looks idempotent (`findChild` returns
null), so I
suspect it's fine — but it's the one behavioural change here that reaches
outside
openejb-core. Could you deploy a war with an unsatisfied `@Inject` into a
real TomEE
and confirm the log is clean? The openejb-core unit test can't see this.
Nit: `catch (final Exception expected)` in the test is broad enough that it
would still
pass if the deployment started failing for an unrelated reason. Asserting on
`DeploymentException` would keep it guarding the branch you actually fixed.
Issue Time Tracking
-------------------
Worklog Id: (was: 1032353)
Time Spent: 20m (was: 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: 20m
> 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)
