[
https://issues.apache.org/jira/browse/TOMEE-4642?focusedWorklogId=1031923&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031923
]
ASF GitHub Bot logged work on TOMEE-4642:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jul/26 19:02
Start Date: 23/Jul/26 19:02
Worklog Time Spent: 10m
Work Description: jungm opened a new pull request, #2848:
URL: https://github.com/apache/tomee/pull/2848
## What
When a war's `web.xml` or annotations name a servlet, filter or listener
class that is **not packaged in the war**,
`AnnotationDeployer.ProcessAnnotatedBeans.deploy(WebModule)` rethrew the
`ClassNotFoundException`/`NoClassDefFoundError` as an `OpenEJBException`. That
propagates out through `ConfigurationFactory.configureApplication` and aborts
startup of the **whole** web context.
This changes the servlet, filter and listener paths to log a warning and
continue instead of failing.
## Why
These `classLoader.loadClass(...)` calls exist only to feed the annotation
scanner. A class that cannot be loaded simply contributes nothing to scan โ it
should not bring the context down.
The old behaviour was also internally inconsistent: the taglib-listener loop
right below, and the servlet *name-fallback* case, already only logged and
continued. Only the explicit-class servlet/filter/listener paths were fatal.
Jakarta Servlet 6.1 ยง2.3.1 ("Loading and Instantiation") permits servlet
loading to be *"delayed until the container determines the servlet is needed to
service a request"*, so deferring an unresolved class rather than failing
eagerly at deploy time is spec-compliant. If such a component is actually used,
Tomcat still surfaces the missing class per-component.
The `WsDeployer` throw for webservice servlet classes was intentionally left
as-is, since a WS endpoint genuinely cannot be built without its class.
## Also
Fixed off-by-one `MessageFormat` placeholder indices (`{1}{2}{3}` โ
`{0}{1}{2}`) in the four related `logger.debug` calls, which were dropping the
first argument from the message.
## Testing
Added
`AnnotationDeployerTest.missingServletFilterAndListenerClassesDoNotFailDeployment`,
using the class names from the ticket (`TestServlet1`, `AddFilterString`, plus
a missing listener). Verified it is a real regression test: reverting the
servlet fix makes it fail with exactly the reported error (`OpenEJBException:
Unable to load servlet class: ...TestServlet1`), and it passes with the fix.
This is the TomEE-side fix for the two Jakarta Servlet TCK deployments that
triggered the abort (`RegistrationTests` naming filter `AddFilterString`;
`DefaultMappingTests` naming servlet `TestServlet1`). Removing the
corresponding entries from `runner-standalone/exclusions/servlet.txt` in the
apache/tomee-tck harness and confirming both classes pass is a follow-up in
that separate repo.
Jira: https://issues.apache.org/jira/browse/TOMEE-4642
๐ค Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1031923)
Remaining Estimate: 0h
Time Spent: 10m
> Deployment fails when a war lists a servlet or filter class it does not
> package
> -------------------------------------------------------------------------------
>
> Key: TOMEE-4642
> URL: https://issues.apache.org/jira/browse/TOMEE-4642
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Reporter: Markus Jung
> Assignee: Markus Jung
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a war's deployment descriptor or annotation names a servlet or filter
> class, but the class is not in the war, TomEE aborts startup of the whole
> context. Two Jakarta Servlet TCK deployments trigger this: the pluggability
> {{RegistrationTests}} deployment names filter {{AddFilterString}}, and the
> spec {{DefaultMappingTests}} deployment names servlet {{TestServlet1}}.
> Neither class ships in its war.
> Both contexts fail to start. Every test method in both classes then errors,
> since each method needs a working deployment URL and gets none.
> The Servlet 6.1 spec calls for strict checks on registered components, but a
> missing class should not bring down the full context. The current behaviour
> treats a single unresolved servlet or filter reference as fatal to the whole
> deployment, when the failure should stay local to that class.
> h2. Steps to reproduce / TCK reference
> * TCK test classes: {{RegistrationTests}} (Jakarta Servlet TCK,
> pluggability), {{DefaultMappingTests}} (Jakarta Servlet TCK, spec)
> * Deploy the wars used by these classes; each names a servlet or filter class
> it does not package ({{AddFilterString}} for {{RegistrationTests}},
> {{TestServlet1}} for {{DefaultMappingTests}})
> * Result: context startup fails, all methods in both classes error on the
> missing deployment URL
> * Currently excluded in: {{runner-standalone/exclusions/servlet.txt}} (2
> class entries, 12 methods) in the apache/tomee-tck harness repo.
> * Remove the exclusion entries once fixed and confirm both classes pass
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
