RE: RE : Antwort: Re: Customize FileUpload to store files directly into database

[Eric Pugh <ep...@upstate.com>]

How about submitting these changes back?  I think what you suggested about
adding another layer to abstract the disk versus non disk stuff was a good
suggestion.

> -----Original Message-----
> From: Voyer Henry [mailto:Henry.Voyer@loto-quebec.com]
> Sent: Friday, October 31, 2003 7:18 PM
> To: 'Jakarta Commons Users List'
> Subject: RE : Antwort: Re: Customize FileUpload to store
> files directly
> into database
>
>
> 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]
> Envoyé : 31 octobre, 2003 12:58
> À : 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 am
> not done with testing yet.
>
> I found FileItem somewhat awkward to implement in my
> DatabaseFileItem class,
> 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 keep
> the form fields in memory, I have to treat form fields
> separately. Currently
> 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
>
>
>
>
>
>
>
>              Martin Cooper
>
>              <ma...@apache.org>
>
>
> An:
>              22.10.2003 05:33                    Jakarta
> Commons Users List
>
>              Bitte antworten an
> Kopie:
>              '"Jakarta Commons Users
>
>              List"'
> Blindkopie:
>
>
>
> Thema:
>
>
>                                                  Re:
> Customize FileUpload to
> store files directly into database
>
>
>
>
>
>
>
>
> On Tue, 21 Oct 2003 Steffi.Rauschenbach@bahn.de wrote:
>
> > Hi,
> >
> > I want to store uploaded files directly into database instead of
> > keeping them in memory or storing them temporarlily to disk. The
> > 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:
> > Document usage of factories and subclassing for customization"
> > (http://jakarta.apache.org/commons/fileupload/customizing.html).
> >
> > Has anyone tried this yet and/or knows how to customize FileUpload
> > 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 form
> 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 stream
> 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 trick
> 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, you
> 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
> > be available?
>
> As soon as I find some time to write it down, with some code
> fragments, and
> get it on the web site. ;-) Having just changed jobs
> recently, I'm a little
> busy right now...
>
> --
> Martin Cooper
>
>
> >
> > Thank you!
> >
> > Steffi
> > ____________________________________________________
> > Internetauftritt der Deutschen Bahn AG >> http://www.bahn.de
> >
> > ---------
> >
> > Diese E-Mail könnte  vertrauliche und/oder rechtlich geschützte
> > Informationen enthalten. Wenn Sie nicht der richtige Adressat sind
> > oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
> > sofort den Absender und 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
> you
> > 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
>
>
>
>
>
> ---------
>
> Diese E-Mail könnte vertrauliche und/oder rechtlich
> geschützte Informationen
> enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den
> Absender und
> 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 you
> 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


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