Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Message-ID: <402AFA83.9000207@leverageweb.com>
Date: Wed, 11 Feb 2004 23:01:07 -0500
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: FileUploadsWithFlow problem
References: <001701c3f0f2$3dee38c0$4690c950@hawk>
In-Reply-To: <001701c3f0f2$3dee38c0$4690c950@hawk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org