Hi James,

Thank you for your email. I think this should be two PRs against git
master, with unit tests of course ;-)

HTH,
Gary

On Mon, Aug 14, 2023, 12:50 PM James Reeves <jree...@weavejester.com> wrote:

> Hello!
>
> I currently maintain the HTTP server library (Ring) for the Clojure
> programming language, which is a functional lisp for the JVM. In order to
> parse multipart requests, I lean on FileUpload. In the past that's been
> somewhat problematic, as 1.x had a hard dependency on Java servlets, so I
> was happy to see that for 2.0.0, the core module of FileUpload has no such
> dependencies.
>
> However, one element of Java that Clojure handles somewhat poorly are
> abstract classes. It's nothing insurmountable,  and I understand that
> FileUpload is a Java library first and foremost, but it would help if there
> was an implementation of AbstractFileUpload that operated directly on the
> RequestContext.
>
> To provide some context, at a high level, my usage is as follow:
>
> 1. Create an implementation of AbstractFileUpload, and stub out the
> abstract methods with dummy code.
> 2. Set the progressListener and fileSizeMax options.
> 3. Create a RequestContext from the Clojure request map.
> 4. Call getItemIterator and use the FileItemInputIterator to iterate over
> the FileItemInput objects.
> 5. Convert those objects into a Clojure-friendly structure.
>
> Obviously this means I'm only using a small slice of the API, and probably
> in a rather unusual way compared to most users. However, I'm wondering if
> there's some way of avoiding needing to create a stubbed out
> AbstractFileUpload, as I don't actually need either of the abstract methods.
>
> Also, I'm not sure whether this deserves its own post, but I found that
> fileSizeMax may have an off-by-one error. In my tests for FileUpload 1.5,
> if I have a fileSizeMax of 9, and send a multipart item that is 9 bytes, it
> passes without an exception. However, in 2.0.0, I needed to increase the
> fileSizeMax to 10 in order to send the same 9 bytes.
>
> --
> James Reeves
>
>

Reply via email to