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]

Reply via email to