Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Message-ID: 
 <9FEDCF7444FBD411BFB700508BF7F230085BDB66@legreco.le500.loto-quebec.com>
From: Voyer Henry <Henry.Voyer@loto-quebec.com>
To: 'Jakarta Commons Users List' <commons-user@jakarta.apache.org>
Subject: RE : Antwort: Re: Customize FileUpload to store files directly in
	to database
Date: Fri, 31 Oct 2003 13:18:12 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steffi

Im interested in this piece of code. Could you give me a link to it?

Thanks a lot.

Regards

henry

-----Message d'origine-----
De : Steffi.Rauschenbach@bahn.de [mailto:Steffi.Rauschenbach@bahn.de]=20
Envoy=E9 : 31 octobre, 2003 12:58
=C0 : Jakarta Commons Users List
Objet : Antwort: Re: Customize FileUpload to store files directly into
database


Hi Martin,

Thank you for the hints! It really helped me to get started.
It took me a while since I had some other things to do, but now I got my =
own
classes for storing the uploaded files directly in database. However, I a=
m
not done with testing yet.

I found FileItem somewhat awkward to implement in my DatabaseFileItem cla=
ss,
because FileItem contains many methods that make only sense when the
uploaded file is written to disk, e.g. isInMemory(). Also, since I store =
the
uploaded file as Blob in the database, it is probably not a good idea to
provide them as byte[] (method get()). So I believe a separate interface
above FileItem is needed that abstracts from the special disk stuff, i.e.
contains only the "basic" methods.

Since I want to store only the uploaded files directly in database, and k=
eep
the form fields in memory, I have to treat form fields separately. Curren=
tly
I use the somewhat dirty solution that I create DefaultFileItems for form
fields, so I don't have to take care of them in my DatabaseFileItem.

What I did (in short, if anyone is interested I can provide more info):

- DatabaseFileItem (used instead of DefaultFileItem)
- DatabaseFileItemFactory (used instead of DefaultFileItemFactory)
- DatabaseFileOutputStream (used instead of DeferredFileOutputStream and
ThresholdingOutputStream, extends OutputStream)
- DatabaseFileUpload (used instead of DiskFileUpload)
- DatabaseFileItemAccessor (contains all the jdbc code to access the
database).

So what I really use from the fileupload lib is:
- FileUploadBase
- MultiPartStream
- Interface FileItem
- Interface FileItemFactory

Steffi


=20

             Martin Cooper

             <martinc@apache.org>

=20
An:=20
             22.10.2003 05:33                    Jakarta Commons Users Li=
st

             Bitte antworten an
Kopie:=20
             '"Jakarta Commons Users

             List"'
Blindkopie:=20
=20

=20
Thema:=20
=20

                                                 Re: Customize FileUpload=
 to
store files directly into database                       =20
=20

=20


On Tue, 21 Oct 2003 Steffi.Rauschenbach@bahn.de wrote:

> Hi,
>
> I want to store uploaded files directly into database instead of=20
> keeping them in memory or storing them temporarlily to disk. The=20
> documentation
> (http://jakarta.apache.org/commons/fileupload/using.html) says that to
get
> this done, I have to customize FileUpload. However, the description of
how
> to do this customization is not available yet - the page says: "TODO:=20
> Document usage of factories and subclassing for customization"=20
> (http://jakarta.apache.org/commons/fileupload/customizing.html).
>
> Has anyone tried this yet and/or knows how to customize FileUpload=20
> properly?

I've done this as part of a Struts app. I don't have the code any more,
since I've changed employer since then, but I'll try to give you a rough
idea of what I had to do.

What you'll need to do is create your own FileItem implementation, along
with a factory to create those. Your getOutputStream() implementation is
where the work happens. There, you'll probably want to make a decision on
what kind of stream to return, based on whether or not the field is a for=
m
field or a file upload.

For regular form fields, I used a ByteArrayOutputStream, since those are
generally fairly short. For file upload fields, I returned a custom strea=
m
implementation that fed the data straight to the database.

In the latter case, you're going to need some context to obtain your
connection or EJB or whatever. This is where the factory comes in. The tr=
ick
is that you can provide the factory with your context (e.g. the request
object) and have it pass that to each FileItem it creates.

One thing to watch out for is that there is no notification mechanism to
allow you to find out that a particular file upload item has finished
uploading, other than the close() method on the output stream you return.=
 If
you need to release a connection as soon as a particular item has been
parsed, then you'll need to do that in your close() method. Otherwise, yo=
u
can do cleanup after parseRequest() completes.

That's about all I can recall off the top of my head, but hopefully it's
enough to get you started.

> When will the documentation on the Apache FileUpload customizing page=20
> be available?

As soon as I find some time to write it down, with some code fragments, a=
nd
get it on the web site. ;-) Having just changed jobs recently, I'm a litt=
le
busy right now...

--
Martin Cooper


>
> Thank you!
>
> Steffi
> ____________________________________________________
> Internetauftritt der Deutschen Bahn AG >> http://www.bahn.de
>
> ---------
>
> Diese E-Mail k=F6nnte  vertrauliche und/oder rechtlich gesch=FCtzte=20
> Informationen enthalten. Wenn Sie nicht der richtige Adressat sind=20
> oder diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte=20
> sofort den Absender und vernichten Sie diese Mail. Das unerlaubte=20
> Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht=20
> gestattet.
>
> This e-mail may contain confidential and/or privileged information. If
you
> are not the intended recipient (or have received this e-mail in error)=20
> please notify the sender immediately and destroy this e-mail. Any=20
> unauthorised copying, disclosure or distribution of the material in=20
> this e-mail is strictly forbidden.
>
> ----------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------

Diese E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte Inform=
ationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender un=
d
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If yo=
u
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

----------


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org