You wrote... "The uploaded data is stored in a temporary file somewhere on
disk.....The bean is in either request or session scope..... If the bean
goes away, then so does the file that holds the uploaded data."
I thought you said the file was written to disk? Thus the binary is not in
the bean. Or is it that the FormFile has all this data and IT is in the
bean. So I end up with a file on disk that is in a state of not be
associated with anything yet, and whos filename and input field names I have
lost when the bean went away. Is that it? If we are keeping the FormFile
in the bean, in the session and the FormFile indeed does contain the binary,
than this is a bad thing. We should at theleast kill the binary from the
FormFile object so we CAN safely put it in the session. (Dont know if I
mentioned by weblogic croaks/freaks if the session has too much "k" in it.
----- Original Message -----
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]>
Sent: Monday, June 11, 2001 1:55 AM
Subject: Re: uploading file requires immediate serialization location?
> String parameters are not written to a file. Only the bodies of file
upload
> parts are written to disk, and each one to a separate file. The files are
> written as the input stream (i.e. the request) is processed.
>
> Let's say your form has two fields, a textarea called 'myText' and a file
> input called 'myFile'. After you submit it, and Struts has populated your
> form bean, you will have:
>
> 1) The text from the textarea field is stored in the bean's 'myText'
> property as a String.
> 2) The uploaded data is stored in a temporary file somewhere on disk.
> 3) The 'myFile' property on your bean, which has type FormFile, contains
> information about the uploaded data (e.g. file name, content type, etc.).
>
> The bean is in either request or session scope, as you defined it in your
> struts-config.xml file. If the bean goes away, then so does the file that
> holds the uploaded data.
>
> Hope this helps.
>
> --
> Martin Cooper
>
>
> ----- Original Message -----
> From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, June 10, 2001 10:48 PM
> Subject: Re: uploading file requires immediate serialization location?
>
>
> > So do you simultaneously write to a file while reading a String
parameter
> > when you process a form? What parts of the multipart request do we save
> in
> > the bean, and in what scope?
> >
> > ----- Original Message -----
> > From: "Martin Cooper" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>; "Jonathan Asbell"
> <[EMAIL PROTECTED]>
> > Sent: Monday, June 11, 2001 1:23 AM
> > Subject: Re: uploading file requires immediate serialization location?
> >
> >
> > > Yes, I think you've got it. Just to be clear, though, when you say "we
> > need
> > > to examine the sections in the header ...", the "we" here is Struts -
> you
> > > don't need to do anything in your application. Struts makes
> getParameter()
> > > et all work for multipart requests as well as regular requests.
> > >
> > > What you are seeing in the packages you've looked at is the parsing of
a
> > > MIME part. The fields in a multipart/form-data request each conform to
> the
> > > specification for a MIME part, and they are separated by a boundary,
> which
> > > is a line containing a pattern defined in a header at the top of the
> > > request.
> > >
> > > Each MIME part consists of a sequence of MIME headers, followed by a
> blank
> > > line, followed by the data for that MIME part, known as the body. A
MIME
> > > header takes the form "header-name: value" - for example,
"Content-type:
> > > text/plain". The body is just a bunch of data that conforms to the
> > > statements made about it in the headers.
> > >
> > > Every field in a multipart request is encoded this way. So where a
> regular
> > > query using GET might contain a query string like this:
> > >
> > > ...&author=Martin&...
> > >
> > > a multipart request would represent the same query parameter like
this:
> > >
> > > -----------------------------0123456789--
> > > Content-disposition: form-data; name="author"
> > >
> > > Martin
> > > -----------------------------0123456789--
> > >
> > > For a file upload, the difference is only that the Content-disposition
> > > header will include a file name, and the data can be binary if
> necessary.
> > >
> > > When a multipart handler processes a request, it is reading the data
> from
> > an
> > > input stream provided by the container. Typically, for regular query
> > > parameters, it will store the value in a hash table. For file
> parameters,
> > it
> > > will store the data in a file and retain information about that file.
> The
> > > Struts implementation uses the FormFile interface to provide access to
> > that
> > > information.
> > >
> > > A multipart implementation could do whatever it wanted to with the
data
> > > provided from a file upload. Although the Content-disposition header
may
> > > specify a file name, there is no requirement to store that data as a
> file.
> > > One implementation that would make sense would be to define a size
> > > threshold, and store uploaded objects below that size in memory, while
> > > writing larger ones to disk.
> > >
> > > Regarding form beans and binary data, there is no reason why a field
in
> a
> > > form bean cannot be a byte array. However, by itself that is not very
> > > useful, hence the FormFile interface. If you'll notice, that interface
> > does
> > > in fact have a getFileData() method, which will give you the uploaded
> data
> > > as a byte array. In the current implementation, what that actually
does
> is
> > > load the contents of the file into memory and hand you back that
memory.
> > And
> > > there you have binary data in a form field.
> > >
> > > Hope this helps.
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > ----- Original Message -----
> > > From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Sunday, June 10, 2001 1:19 PM
> > > Subject: Re: uploading file requires immediate serialization location?
> > >
> > >
> > > > Martin, you seem to understand this subject well, so let me take a
> shot
> > > and
> > > > tell me if I am correct:
> > > >
> > > > A multi-part request is a request, but a different one. That is,
with
> a
> > > > regular request things have been abstracted for us nicely with
> > > > "getParameter" etc., but a request submitted as multipart is not
> handled
> > > > nicely for us by the servlet spec and is a whole different animal.
> This
> > > > type of request needs to be handled uniquely (though I dont
understand
> > why
> > > > the servlet spec does not have standard abstractions for it),
because
> it
> > > may
> > > > contain binary non-text content accompanied by regular content. In
> such
> > a
> > > > request we need to examine the sections in the header and parse for
> > > certain
> > > > values we are expecting to separate out the regular text values
> > submitted
> > > > from the binary parts, and then handle the binary parts.
> > > >
> > > > Things I still dont get:
> > > > In all packages I have examined that handle multipart requests,
there
> is
> > > > always a notion of looking for the line ": ", then looking for the
> blank
> > > > line after that, and then reading in binary values that follow the
> blank
> > > > line up until the "boundry" which is a String in a known format (see
> > link
> > > > below). What I dont understand is what are our options in handling
> this
> > > > binary stuff which is not text. Most packages I have seen write it
to
> a
> > > > file. I'm not sure if there is a way to save a binary object at
all,
> > let
> > > > alone save it in a filed value in a bean. How do you store a binary
> > > object
> > > > in a field?
> > > >
> > > > ==============
> > > > REFERENCE
> > > > ==============
> > > > For those interested see this article:
> > > > www.onjava.com/lpt/a//onjava/2001/04/05/upload.html
> > > > Available servlet packages http://www.servlets.com/cos/index.html
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Martin Cooper" <[EMAIL PROTECTED]>
> > > > To: "Jonathan Asbell" <[EMAIL PROTECTED]>
> > > > Cc: <[EMAIL PROTECTED]>
> > > > Sent: Sunday, June 10, 2001 3:01 PM
> > > > Subject: Re: uploading file requires immediate serialization
location?
> > > >
> > > >
> > > > > Good question. What you are really asking is "what does the
> > <html:file>
> > > > tag
> > > > > do?".
> > > > >
> > > > > Struts will generate an <input type="file" ... > tag, where the
> value
> > of
> > > > the
> > > > > 'name' attribute is taken from the 'property' attribute of your
> > > > <html:file>
> > > > > tag. It will also generate a 'value' attribute. Looking at the
> source
> > > > code,
> > > > > it seems that the valueof the 'value' attribute will be the result
> of
> > > > > calling toString() on the FormFile object. Since that object
doesn't
> > > > > override toString(), the result will be nothing useful. On the
other
> > > hand,
> > > > > browsers usually ignore the 'value' attribute anyway.
> > > > >
> > > > > At this point, the original uploaded file is still on the disk,
and
> > will
> > > > > remain there until the form is resubmitted. Then it will be
deleted
> as
> > a
> > > > > part of setting up for parsing the new multipart data.
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > > --
> > > > > Martin Cooper
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> > > > > To: "Martin Cooper" <[EMAIL PROTECTED]>
> > > > > Sent: Sunday, June 10, 2001 5:47 AM
> > > > > Subject: Re: uploading file requires immediate serialization
> location?
> > > > >
> > > > >
> > > > > > Great explanation Martin. Thank you. So what you really have
said
> > is
> > > > that
> > > > > > the stream contents gets turned into a FormFile object. Ok.
Now
> > the
> > > > big
> > > > > > question. You know when a form is not valid it gets sent beack
to
> > the
> > > > > > client as strings which pre-populate the form fields. How will
> this
> > > > occur
> > > > > > in the case of a file input?
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Martin Cooper" <[EMAIL PROTECTED]>
> > > > > > To: <[EMAIL PROTECTED]>; "Jonathan Asbell"
> > > > > <[EMAIL PROTECTED]>
> > > > > > Sent: Sunday, June 10, 2001 12:20 AM
> > > > > > Subject: Re: uploading file requires immediate serialization
> > location?
> > > > > >
> > > > > >
> > > > > > > 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.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
