Page Flow multipart request handling

[Rich Feit <ri...@apache.org>]

Hi all,

I recently entered http://issues.apache.org/jira/browse/BEEHIVE-802 to
make sure we get rid of the "disk" multipart request handling option,
which tied into the deprecated Struts DiskMultipartRequestHandler.  I
feel that it's important for us to remove this option before 1.0, in
order to avoid a backwards-compatibility headache in the future.  (I'm
taking that as a given for now -- if anyone disagrees, shout.)

Using the default (non-deprecated) MultipartRequestHandler brings to
light another issue: Struts provides more options for configuring file
uploads than we expose.  They are:

    - the maximum file size to process for file uploads (default 250M)
    - the maximum file size to retain in memory; beyond this threshold,
a temporary file is written to disk (default 256K)
    - the temporary directory to use for file uploads that pass the
above threshold
    - input buffer size for file uploads (default 4K)

I've got a few feelings about supporting this:

    1) We should support these options directly, but only at a
webapp-configuration level, in beehive-netui-config.xml; not
per-pageflow.  I think we should document *how* to set them per-pageflow
using our "Struts Merge" facility, but that in most cases they're
webapp-wide settings that don't warrant another annotation within
@Jpf.Controller.

    2) We should make the necessary change for BEEHIVE-802, which is to
turn a disk/memory/disabled option into a simple boolean, but we should
wait until the next point release to add these other configuration
settings (which can be set per-pageflow using Struts Merge).

Anyone have any thoughts/opinions about this?

Thanks,
Rich