We had the same problem with our application. First you need to know that an Enterprise JavaBean should now access the filesystem because the filesystem is not transaction aware. Furthermore the EJB solution is critical because it might happen that the container passivates the FileUploadEJB during an upload because the container needs the CPU resources for other tasks. We have developed a normal JavaBean that is initialized by a servlet and bound to the JNDI. The JavaBean behaves like a factory and maintains all open "file sessions". Furthermore we have an EJB that acts as a delegate or fascade to the Bean. Currently we must use an EJB because we of the EJB security and backward compatability. A pure RMI server would be a cleaner solution, however.
Thanks for the solution you gave, woeye.
Since I wrote the problem I realized that EJB is not the best solution for downloading/uploading files. If I used eg. FileInputStream for reading a file into a byte array and the method returned this array, it would be very memory consuming procedure when transferring big files, or when many clients would access this method.
Now I just return to the client a Data Transfer HashMap that contains the URL where the file can be downloaded from. This was the easiest way I think, however, I must use a http or ftp transfer. I plan to write a web application that also can run in jboss (I hope, never tried) and I will be satisfied.
thanks again sharing the pattern you use.
I've exactly the same problem. Do you mind posting your code?