Announcement

**claudiobosticco** · 28 Jun 2026, 00:00

Hi, even though we're only in the process of purchasing 14.1, I occasionally take a look at the new 15.0 examples and browse through the documentation looking for new features. :-)

The new file upload capabilities are very interesting. I read that there will be support for "stream uploads exceeding a size threshold to temporary files on disk." That naturally raises a question for me:

Is there an extension point (or are you planning to introduce one) that allows applications to intercept the upload stream before SmartClient buffers it, so the application can consume the InputStream directly (for example, to upload it to another storage system instead of saving it to the database)?

**Isomorphic** · 28 Jun 2026, 17:52

We hadn't tried to implement an override point for pre-parse processing of the inbound request yet, and probably won't do so (without a sponsor) because:

1. it's very tricky to do any meaningful request processing without causing a full parse of the request (loading all files into server memory)

Just calling request.getParameter() forces full parsing of the request, as does request.getParts(), which you ordinarily call just to discover what's in the request.

To avoid parsing the whole request into memory, you need to go lower-level and parse the request stream yourself.

This is relatively straightforward, but, in order to gather key metadata for SmartClient to route the request to your declared endpoint, we would basically need a new wire protocol where metadata items (like the DataSource ID and operationId) are passed as HTTP headers and/or passed as a separate "file" part.

2. other layers commonly force full request parsing even if we carefully avoid it

Throw in certain Spring Security features, a naive SSO config, certain proxies, Cloudflare, nginx in default mode... lots of things can force request parsing before the SmartClient Server is even invoked.

In a live, multi-layered, cloud-based deployment, you'd need to do some fairly serious analysis to even figure out who is forcing the request parsing.

3. the streaming upload override point would be at an odd point in the lifecycle, requiring lots of docs and testing

The override point would be basically pre- or mid-validation, so, tons of APIs would need documentation saying "this is how this API behaves if you use this rare override point". This gets particularly complex with security guarantees (for example: "am I before or after requiredWhen for binary fields"?)

That's not at all insurmountable, but it makes it a significant chunk of work.

---

For you, probably the best approach here may be to use AI to generate & test some code to parse requests and to store what you need to via streaming. Then, after storage is successful, when you need to update the database to link to the newly stored data, just create DSRequests via new DSRequest(), in the style of "Standalone DataSource Usage" [1], normally used for command-line and other non-servlet situations.

If you prefer to handle less of the problem, sponsoring a complete "streaming upload" API is an option, or alternatively, you could just sponsor the work to make the custom implementation as simple as possible: you'd own the code for direct request handling, but framework APIs make it so that it's as short and simple as possible.

(we'd actually prefer the latter, since then no one would be asking us "why was the complete request parsed anyway?" when it wasn't our fault)

---
[1] https://smartclient.com/smartclient-...ataSourceUsage

Announcement

Issues found in v15.0 examples

Comment

Comment