Hi Geoff, first of all, thanks a lot for your help. I read through your mails carefully and tried to figure out what you are saying. I must admit some of it is still above me, but I'm trying hard to catch up. Please bear with a newbie who's trying hard to get grips with the whole Cocoon concept.
Here's the test I did: Set web.xml to - enable-uploads : true - autosave-uploads : false added to config.xconf, just below the root node: <upload_manager> <!-- from shorthand in roles file --> <uploadfolder>D:\java\Tomcat13\webapps\bvar\data2</uploadfolder> </upload_manager> I used a full path because I'm using a windows system. :-/ As the final web server is also a windows system, I have no alternative at this point (sadly enough). I set the log levels to DEBUG to get more appropriate error messages. I get no errors starting up tomcat 4.1.29 When uploading a file (C:\test.txt) I get the following error : "file:/D:/java/Tomcat13/webapps/bvar/admin/edit/system/scripts/receiveImages .js", line 7: uncaught JavaScript exception: at upload (file:/D:/java/Tomcat13/webapps/bvar/admin/edit/system/scripts/receiveImages .js, Line 7): java.io.FileNotFoundException: D:\java\Tomcat13\webapps\bvar\data2\C:\test.txt (The filename, directory name, or volume label syntax is incorrect) Line 7 contains "var success = uploader.upload (part);" I'm trying to dive into this and solve it. I'm not good at this kind of thing yet, so hints are definately welcome. Obviously the path of the file to be written to disk is not built up correctly. Checking the UploadManagerImpl.java file doesn't show anything wrong yet (to me :-/ ). Still looking .... Thanks, Bert ----- Original Message ----- From: "Geoff Howard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 12, 2004 5:01 AM Subject: Re: FileUploadsWithFlow problem > Bert Van Kets wrote: > > Hi all, > > I have finally gotten the FileUploadsWithFlow sample working without errors, > > but I still can't see anything arriving on the server. :-( > > Finally got a chance to look at this tonight, and I think I have > answers. I have not tested any of this, so it's all fresh from 5 > minutes in the patch code, and cvs (all while watching a very > interesting show on the Medicis...). Point is, check what I'm saying - > I could be wrong. > > > I get no error anywhere. Not in the console, not in the browser, not in the > > logs. The Flow script throws me to the success page, which should mean the > > object was successfully created. > > I think you're right. The logs should go into core.log, but the default > logging level (set in logkit.xconf, modified if desired by build > properties) is WARN or ERROR now. So, to see the .debug() level as in > this case, you need to modify it to lower to DEBUG. > > >>From what I read in the FileUploadManager.java file the upload directory is > > taken from the context. But regardless of what I set in web.xml I see > > nothing hapening there. > > I know that Cocoon removes the files from the upload directory at the end of > > teh request, but is this also the case here? After all the file is manually > > written to disk. > > Yes, this is a flaw of the upload manager component as written - because > it uses the upload dir in web.xml as the default destination dir, the > default behavior is to rename a PartOnDisk to the same file name. When > the files are cleaned up at the end of the request in 2.1.3 and before > all PartOnDisks in the Request are looped over and the underlying File > deleted (even though you've "resaved" it). Ironically, because the code > in 2.1.3 looks for PartOnDisk, if you set autosave to false the > PartInMemorys will be skipped over during cleanup and the file would > survive. > > To use the component as is, simply configure a different upload dir, > which you can do from reading the component info by adding this > somewhere as a top-level child in cocoon.xconf: > > <upload_manager> <!-- from shorthand in roles file --> > <uploadfolder>/any/other/dir</uploadfolder> > </upload_manager> > > There is a new feature in current cvs, about to be released in 2.1.4 > which mitigates this issue, but the component needs to be modified to > take advantage of it. Three new methods are added to Part, but the > important one is called setDisposeWithRequest(boolean) which you can use > to signal the framework to leave this item alone. The default if you do > not set it is true (erase at end as now). So, with this you no longer > need a component for the simplest case: uploading all files to one > directory, set in web.xml. You could in your flowscript just get the > Part as described now on the wiki and call > part.setDisposeWithRequest(false). C'est tout. > > > What do I need to set in the web.xml file to get things running? Do I need > > to copy the file to a different directory again after the FileUploadMagager > > has already written it to disk? > > Just to make sure you understood the above, you should be able to > provide several interesting answers to these questions yourself now... > > > If I get this running I promise I'll update the Wiki page so it's more > > usable for newbies like me. > > Please do. There is also a problem with the component example code at > the bottom - I posted a fix for that recently on the list (within the > last week). > > Geoff > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
