Let me see if I can describe the process.
1. Check to see if the request should be treated as multipart (i.e. content
type is multipart/form-data and method is POST). If not, carry on as normal.
2. Find the multipart handler or instantiate one, set it on the form bean,
and call it to handle the request.
2a. Iterate over the fields (parts) in the request.
2a1. If the current part is not a file, store it as a String.
2a2. If the current part is a file (according to the Content-Disposition
header), create a new file in the temp directory, stream the content of the
part to that file, create a new object which implements FormFile, and store
the file data in it.
2b. Turn the set of fields into something that looks like regular request
parameters.
3. Populate the ActionForm instance from the set of request parameters.
Here, the value of a file parameter has type FormFile, so it matches a
setter on the form bean that takes a FormFile as a parameter.
That's the gist of it, although there are some other nitty gritty details.
Almost all of this happens inside the code that populates the form bean from
request parameters.
It appears (from my reading of the source, anyway) that the temporary files
will not be automatically deleted until another request comes in that uses
the same form bean instance, or until the form bean instance goes away.
Given that, I would recommend calling setMultipartRequestHandler(null) from
your form bean's reset() method if you keep your beans in session scope.
The part you are interested in, I believe, is 2a2 above. Unfortunately, that
code is buried inside an iterator class, so you can't override just that
piece. I assume what you would want is that the data is kept in memory
instead of to a file. Interestingly, I believe the original implementation
did this, but it was changed to use files because of potential memory
problems with large uploads.
Hope this helps.
--
Martin Cooper
----- Original Message -----
From: "Jonathan Asbell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 09, 2001 8:11 PM
Subject: Re: uploading file requires immediate serialization location?
> Hello Martin. So is it POSSIBLE to save binary data in a bean? What does
> struts do? These are my real questions. If I have a form which besides
> fields, has an uploaded file, how does the bean actually handle the file?
> Is there a conceptual step by step you can give me. How does the
ActionForm
> save (and validate) the binary data sent via input type "file".
>
>
> ----- Original Message -----
> From: "Martin Cooper" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Jonathan Asbell"
<[EMAIL PROTECTED]>
> Sent: Saturday, June 09, 2001 10:55 PM
> Subject: Re: uploading file requires immediate serialization location?
>
>
> > Internally to Struts, multipart handling is provided through an
interface,
> > MultipartRequestHandler. In Struts 1.0, the only supplied implementation
> of
> > this interface is DiskMultipartRequestHandler, which, as you might
expect,
> > writes "file" parts to disk as it encounters them.
> >
> > Struts does allow you to configure the multipart handler to use, by
> > specifying the class name in the multipartClass init-param for your web
> app.
> > This allows you to provide your own implementation if you want to
> (although
> > this is no small task).
> >
> > --
> > Martin Cooper
> >
> >
> > ----- Original Message -----
> > From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, June 09, 2001 6:39 AM
> > Subject: uploading file requires immediate serialization location?
> >
> >
> > Hello all.
> > I am just trying to understand an aspect of a multipart request. When
> > you submit after using an input of type "file", do you have to provide
> > an immediate location for the file to be serialized to, or can you store
> > it in a java object (in a bean's field) as a binary object until you are
> > ready to serialize it. The reason is that I want to hold a jpeg in a
> > bean until the person completes the last page of the form, and THEN
> > serialize it.
> >
> >
> >
> >
>
