Quoting "Eric H. Jung" <[EMAIL PROTECTED]>: > 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 > [EMAIL PROTECTED] > Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
