It is using FilePart (see last email). > -----Original Message----- > From: Nathaniel Alfred [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 24, 2003 10:27 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: FileUpload in mod-db / HttpRequest.getParameter() > > > Folks, hold it. Aren' you missing the OO bit here. > Just use FilePart and the autosave-uploads setting doesn't matter. > > These are the helper methods I'm using with HEAD: > > /** > * For upload request parameters, return the InputStream from where > * to read the data. > * Returns <code>null</code> if no such request parameter. > */ > public static InputStream getUploadDataStream(Request request, > String name) { > try { > // Using MultipartRequestFactoryImpl as RequestFactory. > FilePart filePart = (FilePart)request.get(name); > return filePart.getInputStream(); > } > catch( Exception ignore ) {} > return null; > } > > /** > * For upload request parameters, return the filename. > * Returns <code>null</code> if no such request parameter. > */ > public static String getUploadFilename(Request request, > String name) { > try { > // Using MultipartRequestFactoryImpl as RequestFactory. > FilePart filePart = (FilePart)request.get(name); > return filePart.getFilePath(); > } > catch( Exception ignore ) {} > return null; > } > > Wouldn't it be cool to have these as part of the o.a.c.e.Request > interface? > > Cheers, Alfred. > > -----Original Message----- > From: Geoff Howard [mailto:[EMAIL PROTECTED]] > Sent: Freitag, 24. Januar 2003 16:17 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: FileUpload in mod-db / HttpRequest.getParameter() > > > even weirder - I was using FilePartArray (i think - see below). I'm > using > straight out of cvs, and the default in web.xml is > <init-param> > <param-name>autosave-uploads</param-name> > <param-value>false</param-value> > </init-param> > > Which should make it use FPArray. The only glitch is that I have a > parallel > webapp deployed in the same container which has autosave-uploads set to > true. I'll add some debugging to show what kind of object it's finding > and > get back to you. > > Which jdk are you using? > > Geoff > > > -----Original Message----- > > From: Christian Haul [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 24, 2003 9:34 AM > > To: Geoff Howard > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: FileUpload in mod-db / HttpRequest.getParameter() > > > > > > Goeff, > > > > thanks for your patch to use MultiPart with the DatabaseActions. > > > > On 24.Jan.2003 -- 12:22 AM, Geoff Howard wrote: > > > Anyway, it's all working now, autoincrement, inserting the data, and > the > > > database reader (pending the patch). > > > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16382 > > > > However, it does not work for me! It took me quite a long time with > > the debugger to find the reason for this (now to the reason I cc'ed > > Jeroen and cocoon-dev): > > > > If FilePartArray is used the uploaded file is stored inside the > > request object. Fine. But how to access it there? > > HttpRequest.getParameter() returns java.lang.String and thus > > JDBCTypeConversions.storeColumn() tries to open a file named > > "org.apache.cocoon.components.request.multipart.FilePartArray@234768" > ! > > > > In which situations does FilePartArray work at all? Or is this class > > completely useless? > > > > Any idead how to make this work? > > > > Would it be better to pass the uploaded file through a request > > attribute? > > > > Is there some backward compatibility issue with placing the file name > > in a request parameter? > > > > Would it make sense to create an input module that first checks the > > request attribute for an FilePartArray and if not found asks the > > request parameter for the file name? > > > > Chris. > > -- > > C h r i s t i a n H a u l > > [EMAIL PROTECTED] > > fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > This message is for the named person's use only. It may contain > confidential, proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any mistransmission. > If you receive this message in error, please notify the sender urgently > and then immediately delete the message and any copies of it from your > system. Please also immediately destroy any hardcopies of the message. > You must not, directly or indirectly, use, disclose, distribute, print, > or copy any part of this message if you are not the intended recipient. > The sender's company reserves the right to monitor all e-mail > communications through their networks. Any views expressed in this > message are those of the individual sender, except where the message > states otherwise and the sender is authorised to state them to be the > views of the sender's company. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
