[
https://issues.apache.org/jira/browse/WW-3526?focusedWorklogId=1047771&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1047771
]
ASF GitHub Bot logged work on WW-3526:
--------------------------------------
Author: ASF GitHub Bot
Created on: 16/Oct/26 07:55
Start Date: 16/Oct/26 07:55
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #359:
URL: https://github.com/apache/struts-site/pull/359
Refs [WW-3526](https://issues.apache.org/jira/browse/WW-3526)
WW-3526 asked for a framework-managed upload progress listener. It is being
closed as Won't Fix because browsers now report upload progress through
`XMLHttpRequest.upload` events. This adds an "Upload Progress" section to
`core-developers/action-file-upload.md` covering both options:
- **Client side (recommended):** an `xhr.upload.onprogress` snippet.
- **Server side:** subclass `JakartaMultiPartRequest`, keep the request from
`parse(...)`, set a Commons FileUpload `ProgressListener` in
`prepareServletFileUpload(...)`, and register the subclass as a
`MultiPartRequest` bean selected by `struts.multipart.parser`.
## Verification
- The Java example was compiled against current `apache/struts` main core.
- `bundle exec jekyll build` succeeds, and the new section renders.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1047771)
Remaining Estimate: 0h
Time Spent: 10m
> Augment JakartaMultiPartRequest to include optional progress listener
> ---------------------------------------------------------------------
>
> Key: WW-3526
> URL: https://issues.apache.org/jira/browse/WW-3526
> Project: Struts 2
> Issue Type: New Feature
> Components: Dispatch Filter
> Affects Versions: 6.1.1
> Environment: N/A
> Reporter: Bob Glamm
> Priority: Minor
> Fix For: 7.5.0
>
> Attachments: upload-listener.tar.gz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Original concept from David Casserly: see
> http://www.devedup.com/ajaxfileupload/
> The basic idea is to augment JakartaMultiPartRequest to allow users to
> specify a file upload progress listener (see Commons FileUpload
> ServletFileUpload.setProgressListener()). The original concept by Casserly
> references a specific ProgressMonitor class that implements FileUpload's
> ProgressListener interface. I'd propose an alternate solution: allow the
> user to configure the fully-qualified name of an optional listener class via
> @Inject("struts.multipart.monitor"), then:
> o require the listener class to also implement an interface that specifies
> public void abort(); as its only method;
> o in JakartaMultiPartRequest.parseRequest(), attempting to instantiate the
> specified listener class via Class.forName().newInstance();
> o store the instantiated listener in the session, as per Casserly's
> example;
> o in JakartaMultiPartRequest.parse(), in the catch(FileUploadException)
> block, calling the abort() method on the listener class if it is in the
> session.
> Users can then implement an action that retrieves the upload status (via AJAX
> or some other mechanism) by retrieving their listener object from the session
> (as per Casserly's example.) AJAX retrieval allows implementation of file
> upload progress bars, a la GMail's attachment upload mechanism.
> One possible issue I see with this is: what happens if multiple file upload
> requests happen simultaneously for a user session?
> I have a partial implementation but I'm not familiar with the Struts
> development process or philosophies, so I'm throwing this out there for
> review. If there are better ways to do this, let me know. I can
> (eventually) provide a patch to 2.2.1 or HEAD with a little assistance, I
> think.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
