[Fileupload] Progress bar

["Eric H. Jung" <ej...@russellmellon.com>]

Sorry for not replying to the thread started by Eric Pugh at
http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg32368.html,
but I've only just joined commons-dev as suggested to me by Yoav on
tomcat-dev.
We were discussing a related topic there.

I've gone through signifcant efforts to extend commons-fileupload using
Listener interfaces
in order to support a progress bar to no avail. I researched what others
have done,
including but not limited to
http://www.javazoom.net/jzservlets/uploadbean/uploadbean.html
(which, by the way, seems to redistribute commons-fileupload without any
mention of Apache).

I do not see how this problem can be tackled without writing one's own (or
extending another)
servlet container. There is currently no way in the servlet spec to know the
number of bytes
that have been read as a ServletRequest is being processed. By the time
Servlet.service() or
Filter.doFilter() are called, the *entire* InputStream has been read from
the socket, leaving no
way to provide user feedback during the upload.

I could be totally off base here, and if I am, I'd appreciate it if someone
would show me the light.

Thank you,
Eric H. Jung
ejung@russellmellon.com





---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Fileupload] Progress bar

["Craig R. McClanahan" <cr...@apache.org>]

Quoting "Eric H. Jung" <ej...@russellmellon.com>:

> Sorry for not replying to the thread started by Eric Pugh at
> http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg32368.html,
> but I've only just joined commons-dev as suggested to me by Yoav on
> tomcat-dev.
> We were discussing a related topic there.
> 
> I've gone through signifcant efforts to extend commons-fileupload using
> Listener interfaces
> in order to support a progress bar to no avail. I researched what others
> have done,
> including but not limited to
> http://www.javazoom.net/jzservlets/uploadbean/uploadbean.html
> (which, by the way, seems to redistribute commons-fileupload without any
> mention of Apache).
> 
> I do not see how this problem can be tackled without writing one's own (or
> extending another)
> servlet container. There is currently no way in the servlet spec to know the
> number of bytes
> that have been read as a ServletRequest is being processed. By the time
> Servlet.service() or
> Filter.doFilter() are called, the *entire* InputStream has been read from
> the socket, leaving no
> way to provide user feedback during the upload.
> 

That is not entirely accurate, but is probably true for most scenarios of
interest in trying to do a progress bar for file uploads.

Technically, the servlet input stream is only consumed if either (a) the servlet
explicity reads from it, or (b) you're processing a POST request and call one
of the getParameter() methods.  In such a scenario, you could simply write a
servlet filter that wrapped the incoming request, and fired off the progress
events in your own implementation of ServletInputStream.

However, there are many other environments (such as when you run Tomcat behind
Apache) where the servlet container never even gets a chance to process the
input until after the front-end web server has consumed all or part of the
data.  It's going to be very difficult to implement what you want in such an
environment.

> I could be totally off base here, and if I am, I'd appreciate it if someone
> would show me the light.
> 

My personal opinion is that this kind of thing is not appropriate for the
*servlet* API, which is designed to be a high level abstraction that insulates
you from low level details of HTTP processing.  It would make much more sense
to build it in to a low-level "Java HTTP Server" type API at the same
conceptual level as, say, commons-httpclient provides for being an HTTP
client.

It would be interesting to explore whether one could create such a low level
server API abstraction (perhaps even having a couple of implementations that
explore using asynchronous IO via the NIO calls in J2SE 1.4), and then build
servlet API semantics on top of it.  That way, applicatons that wanted the
simplicity of the servlet API could continue to have it, while someone who just
wanted to embed a simple HTTP server port (say, for administration or
monitoring) wouldn't need to embed a ten megabyte servlet container like
Tomcat.

> Thank you,
> Eric H. Jung
> ejung@russellmellon.com
> 


Craig McClanahan



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Fileupload] Progress bar

[Peter Courcoux <pe...@courcoux.biz>]

Hi Eric,

My implementation using turbine is a bit more complex than this but this
should give you the idea :-

1.	Populate the VelocityContext of the page containing the fileupload
form with a uniqueid to a cached reference to a new instance of a
ProgressReporter object. This is done in the page setup using a turbine
pulltool. 

2. 	I use a time expired cache so that if something goes wrong the cache
cleans up after itself.

3.	Add the unique id to the upload form using a known parameter name.

4.	Add a javascript onClick handler to the form to open a new upload
status window. Pass the unique id to the window.

5.	On form submission, the ParameterParser(request parser) reads the
unique id for the ProgressReporter obtained at 1. It uses this to obtain
the referenced object from the cache and passes this to the upload
service which updates it as the request is read. 

6.	The upload status window uses the same uniqueid it was given at point
4 and again using a pull tool queries the server for the
ProgressReporter object and displays the result. The UploadStatus window
is set to reload every 5 seconds and consequently displays the updated
status. When the ProgressReporter object is released when the request is
completely read, the window is set to close, again using javascript.

This has been working for 7 or 8 months now very successfully.

The server on which this is used regularly receives uploads from a few
Kb to an average of 20MB and occasionally up to its limit of 100MB.
Rather than implement a progress bar, I report the size of the request,
the bytes read and the name of the file object currently being
processed. It would, of course be relatively easy to take this
information and produce a progress bar.

Does this make sense?

I intend to post a detailed set of examples and instructions on the
turbine site (In fact I produced a draft in May or June but I'll have to
review it all again), but only when I have the support in
commons-fileupload. It's no good to anyone until then!

Regards,

Peter


On Tue, 2003-12-23 at 20:29, Eric H. Jung wrote:
> Sorry for not replying to the thread started by Eric Pugh at
> http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg32368.html,
> but I've only just joined commons-dev as suggested to me by Yoav on
> tomcat-dev.
> We were discussing a related topic there.
> 
> I've gone through signifcant efforts to extend commons-fileupload using
> Listener interfaces
> in order to support a progress bar to no avail. I researched what others
> have done,
> including but not limited to
> http://www.javazoom.net/jzservlets/uploadbean/uploadbean.html
> (which, by the way, seems to redistribute commons-fileupload without any
> mention of Apache).
> 
> I do not see how this problem can be tackled without writing one's own (or
> extending another)
> servlet container. There is currently no way in the servlet spec to know the
> number of bytes
> that have been read as a ServletRequest is being processed. By the time
> Servlet.service() or
> Filter.doFilter() are called, the *entire* InputStream has been read from
> the socket, leaving no
> way to provide user feedback during the upload.
> 
> I could be totally off base here, and if I am, I'd appreciate it if someone
> would show me the light.
> 
> Thank you,
> Eric H. Jung
> ejung@russellmellon.com
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
-- 
Peter Courcoux <pe...@courcoux.biz>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org