oscerd opened a new pull request, #9067:
URL: https://github.com/apache/camel-quarkus/pull/9067
Fixes #9055.
`ServletProcessor.newServlet` guarded the multipart wiring with:
```java
MultipartConfig multipartConfig = servletConfig.multipart();
if (multipartConfig != null) {
```
which reads like the conditional treatment the options above it get —
`loadOnStartup`, `async` and `forceAwait` are each genuinely guarded, under a
comment saying so. This one is not: `ServletConfig` is a `@ConfigMapping`
interface and `multipart()` is a non-`Optional` nested group, so SmallRye
always materialises it with its `@WithDefault` values and the check can never
fail.
**Why the config is not made conditional instead**
The issue suggested applying the multipart configuration only when the
deployer configured it. That would be a breaking change. Multipart handling is
deliberately enabled on every Camel servlet, and
`CamelServletTest.multipartDefaultConfig` posts a multipart request to
`/folder-1/multipart/default` — served by the **default** servlet, which has no
`multipart.*` configuration — and expects `200` with the part echoed back.
Making `multipart()` an `Optional` group would leave that servlet without a
`MultipartConfigElement` and break both the test and any application that
consumes multipart requests without configuring anything.
The unlimited `-1` defaults are likewise documented as such on
`max-file-size` and `max-request-size`, so changing them is a separate
behavioural decision rather than a bug fix. See the [issue
comment](https://github.com/apache/camel-quarkus/issues/9055#issuecomment-5422316835)
for the detail.
So this removes the dead branch and records why the wiring is unconditional.
**Behaviour is unchanged.**
**Tests**
All 19 `CamelServletTest` cases pass, including `multipartDefaultConfig` and
`multipartCustomConfig`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
