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 istaken 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]
