You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor!: Decouple Request from HttpExchange to enable swappable transports
Request now holds transport-neutral primitives: body bytes, parsed body,
TypeMapper, operationId, path parameters, raw query string, and a
Function<String,String> header lookup. The JDK HttpServer adapter
(RequestPreparationFilter) is the only place that touches HttpExchange.
Why: keeps the door open to a Netty / Helidon Nima / Jetty backend later
if JDK HttpServer's throughput becomes the bottleneck. The handler-facing
API (Request, Response, RequestHandler, RequestInterceptor,
ResponseDecorator, TypeMapper) is now genuinely transport-neutral — a
future adapter would live in com.retailsvc.http.internal and leave
handler code untouched.
README's 'Performance and caveats' section documents the rationale.
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -433,7 +433,7 @@ The library wraps the JDK's bundled `com.sun.net.httpserver.HttpServer` and uses
433
433
A few things to know:
434
434
435
435
-**Single-process model.** No horizontal scaling primitives are bundled; run multiple instances behind a load balancer for production scale.
436
-
-**JDK HttpServer is the throughput ceiling.** It's documented as a low-throughput / dev-test server. If you need to go materially above the rates above, deploy the same filter/validator/router stack on Jetty, Helidon Níma, or Netty — the spec and validation code is server-agnostic.
436
+
-**JDK HttpServer is the throughput ceiling.** It's documented as a low-throughput / dev-test server. If you need to go materially above the rates above, the handler-facing API (`Request`, `Response`, `RequestHandler`, `RequestInterceptor`, `ResponseDecorator`, `TypeMapper`) is transport-neutral by design — `Request` is built from primitives (body bytes, raw query string, path parameters, a header lookup function), not a JDK `HttpExchange`. A future enhancement could plug in a higher-throughput backend (Jetty, Helidon Níma, Netty) by writing a new adapter behind `com.retailsvc.http.internal` while leaving handlers untouched.
437
437
-**Per-request state uses `ScopedValue`** (Java 25, JEP 506). This matters if a handler offloads work to an executor that's not a `StructuredTaskScope`-managed child thread: the `ScopedValue` is not visible there, so the handler must capture the values it needs (e.g. `byte[] body = request.bytes();`) before submitting.
438
438
-**Empty responses use `Response.empty()` (204) or `Response.status(code)` for other no-body statuses.** The renderer sends `responseLength = -1` (`Content-Length: 0`, no body) for any `Response` with `body() == null`, regardless of status code. Passing `0` to the JDK directly produces a chunked response with zero chunks, which is technically non-conformant — `Response` factories handle this for you.
0 commit comments