Presently there is File Upload requirement in our application.This is a web application deployed in Jboss and has Oracle as Database.We also have a File Server for file storage.We are using Struts as the controller and there are no J2EE layers as such(no transaction..plain vanilla web application...!!). So presently when the user clicks the Mass Upload button an Applet open which allows the user to browse and select the files to be uploaded.Once the submit button is clicked the files are sent as described below - (1)first the file content is streamed to a Temp directory in the web server(TCP/IP tunnel..). (2)the file content is then streamed to the file server (another TCP/IP tunnel). (3)finally user is intimated the success/failure message.
We are analyzing the pros/cons regarding this approach and trying to find out ways to improve.Our conclusion so far: (a)Since we are sending data through TCP/IP there are no size restrictions.Files of any size can be sent.Most web browsers have 2GB and size restrictions so the reluctance of sending data through http.Also it might not be practiccal enough to send large files in http. (b)Users can browse to other pages in the application without affecting the file upload process.
Please help and suggest ways to improve.
To repeat what others have said, requires education, to challenge it , requires brains.
I'm not sure what exactly you're asking. It sounds as if the process is all set up and working fine; which concerns do you have that you'd like to address?
Ping & DNS - updated with new look and Ping home screen widget
Joined: Sep 26, 2006
Ulf Dittmer wrote:I'm not sure what exactly you're asking. It sounds as if the process is all set up and working fine; which concerns do you have that you'd like to address?
What we are looking for is a better way to upload files.The above process is all well and set but is this the best approach for file upload.Some might say it is...well atleast I would, since thats what is running in Production now without frequent hiccups!!..although would like to know whether fellow ranchers have any alternate approach in mind.
Joined: Mar 22, 2005
I think you're approaching this backwards - if the process is working fine technically, and the users are not complaining about it, why change it? If, on the other hand, there are usability or technical problems with it, then you could start to look into alternatives.