paulrutter opened a new pull request, #559: URL: https://github.com/apache/felix-dev/pull/559
`JettyConfig` in the Jetty 12 bundle declares 88 property constants; `http/README.md` mentioned 58 of them. This PR documents the 30 that were absent (28 properties, see the notes below on the other two) and corrects two existing rows. ### Added rows * `org.apache.felix.http.name`, `org.apache.felix.http.path_exclusions` * `org.apache.felix.http.session.container.attribute` * the whole `org.apache.felix.http.requestlog.*` family (15 properties) * `org.apache.felix.https.jetty.session.cookie.httpOnly` / `.secure`, `org.eclipse.jetty.servlet.SessionIdPathParameterName`, `org.eclipse.jetty.servlet.CheckingRemoteSessionIdEncoding`, `org.eclipse.jetty.servlet.SessionScavengingInterval` * `org.apache.felix.https.keystore.type`, `org.apache.felix.https.jetty.renegotiateAllowed` * `org.apache.felix.jetty.relativeredirectallowed`, `org.apache.felix.jetty.statisticshandler.enable`, `org.apache.felix.jetty.stopTimeout` * `org.apache.felix.http.jetty.acceptors`, `org.apache.felix.http.jetty.selectors` All defaults were taken from `JettyConfig` and its consumers rather than from the Config Admin metatype, since the two disagree in places (see below). ### Corrected rows * `org.apache.felix.http.jetty.threadpool.max` was documented as defaulting to unlimited. `getThreadPoolMax()` returns `-1`, and `createServer()` then falls through to `new Server()`, which builds Jetty's default `QueuedThreadPool`. `QueuedThreadPool()` delegates to `this(200)`, so the effective default is 200 platform threads. * `org.apache.felix.http.jetty.virtualthreads.enable` was documented as always using `threadpool.max` for a bounded virtual thread pool. That only holds when `threadpool.max` is actually set. With `threadpool.max` unset — the default — `createServer()` builds a `QueuedThreadPool` with `Executors.newVirtualThreadPerTaskExecutor()`, which is *unbounded*, the opposite of what the row described. ### New sections Two rows were too long to stay readable in the table, so they link to a section instead: * **Thread pool and virtual threads** — the four `threadpool.max` × `virtualthreads.enable` combinations, plus the acceptor/selector and reserved-thread consequences, and a note that Jetty's preferred shape (a `QueuedThreadPool` with a bounded `VirtualThreadPool` as its virtual threads executor) has no Felix HTTP configuration. * **Request logging** — how the `RequestLog` service tracker works and how the two shipped implementations relate to it, since 15 of the added rows belong to that family. ### Notes / follow-ups, not addressed here * `org.eclipse.jetty.security.sessionCreatedSecure` is a string constant in `JettyConfig`, but it is not a property — it is the default *value* of `org.apache.felix.http.session.container.attribute`. That property is documented instead. * The two deprecated misspelled `org.apache.felix.https.jetty.cipersuites.*` variants are left undocumented on purpose, in line with the existing note about legacy property names. * `ConfigMetaTypeProvider` describes `org.apache.felix.https.jetty.renegotiateAllowed` as "true by default", while `JettyConfig.isRenegotiationAllowed()` defaults it to `false`, and it describes `org.apache.felix.http.requestlog.osgi.format` as defaulting to `NCSA_FORMAT`, while the code uses `EXTENDED_NCSA_FORMAT`. The README now follows the code; the metatype descriptions could use a separate fix. * `JettyService.createServer()` labels its bounded branch `// Configurable, bounded, virtual thread executor`, which is the phrase the Jetty documentation uses for the preferred `QueuedThreadPool.setVirtualThreadsExecutor(virtualThreadPool)` shape. The Felix branch passes the `VirtualThreadPool` straight to `new Server(threadPool)`, which is Jetty's separate standalone alternative — same words, different construction. Comment only, no behaviour change, so also left for a separate change. Documentation only, no code changes. 🤖 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]
