Thanks. That is an excellent idea. This is exactly what I need, to have access to the request "as it forms". I am not sure if doing it with a filter is exactly what I need because I was under the impression that a filter is essentially a servlet from the containers perspective, but I am far from an expert in this. I am looking forward hearing from Michael on this matter.
Sincerely, Mashama On 9/2/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Well, I would defer to Michael to answer this, as I don't know the > answer myself, I'd have to go research and figure it out. One thing > that comes to mind though is doing it with a filter (with a > RequestWrapper involved I would think) so you would have access to the > request "as it forms", so to speak. You would spawn a new thread from > the filter, giving is a reference to the wrapper, and continue > processing from there. > > That being said, I do not recall his solution being filter-based, so > there must be another (probably simpler) answer. > > Frank > > Mashama McFarlane wrote: > > Thanks a lot. Actually this is exactly what I was envisioning but my > > problems is that I don' know what type of thread to write to handle the > > upload. I mean I am pretty sure I can't write a servlet thread because I > am > > assuming that the servlet container only passes the servlet the request > > after it has received it in its entirety. Please correct me if I am > wrong, > > but if this is correct then any solution must be at the container level. > So > > the question is what kind of thread? At what level? And is it even > possible? > > Thanks for your help. > > > > Sincerely, > > Mashama > > > > On 9/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > >>Hi, > >> > >>There really is no straight-forward way of doing this. In theory it > >>goes against the basic nature of HTTP. > >> > >>That being said, Michael McGrady implemented such a solution, and > >>hopefully he will see this and be able to talk about it. I'll do my > >>best to remember the basic theory... > >> > >>You start by targeting your form submission to a new window. This is > >>where your progress bar will display. In your servlet that recieves the > >>request that contains the file upload, you spawn a new thread to handle > >>the upload and return immediately with a page with some Javascript to > >>periodically poll the servlet to get the progress of the upload (every 5 > >>seconds for example). The servlet of course has to retain a reference > >>to the thread handling the upload, and it has to have some sort of > >>unique identifier to be able to request the status update. This > >>identifier is passed to the servlet from the progress window. Once the > >>upload completes, a page is returned to inform the user (might be in the > >>popup still, might be a page that redirects the parent window of the > >>popup to a completion page). > >> > >>Michael will hopefully correct me or expand on this as appropriate, but > >>that's what I recall being the basic theory behind his approach. I > >>think his code was on the Struts Wiki at one point, you may want to go > >>have a look and see. > >> > >>-- > >>Frank W. Zammetti > >>Founder and Chief Software Architect > >>Omnytex Technologies > >>http://www.omnytex.com > >> > >>Mashama McFarlane wrote: > >> > >>>I need some help. I am working with file uploads. The ideal file > uploads > >>>will be large enough to justify a file upload progress indicator. I am > >>>trying to figure out the easiest way of doing this, but it is much more > >>>complicated than I originally thought. It would be nice if somebody out > >>>there can prove me wrong on that point. I know that if I can monitor > the > >>>request as it comes into the servlet container, then I can extract out > >> > >>the > >> > >>>content-length and then everything else is a matter of counting bytes, > >> > >>but > >> > >>>where and how do I do this. This cannot happen in the servlet as, I am > >>>assuming, the whole request has been received in its entirity prior the > >>>servlet servicing the request. So where on the totem pole need I be. > >> > >>Please > >> > >>>advise. > >>> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
