Mailing-List: contact beehive-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <beehive-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of mrtidy@gmail.com designates
 64.233.184.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=sCu37x/E2xCiMS03O+/BOpKbfKfsBALz8OjMWv1LsSBXmpFhNO5I1nJewXWaqEFf7Em+bq6tafDzYsQKOpbQNT0iSa0dD6xf7T4Eg0U4SfVpC0PTykJoytBNnxBplAz+MUNzZHRbCI5V0xfMr0imCNqCDhb0lEYyuTTJrp7THDI=
Message-ID: <55c1942005061408222bd9986f@mail.gmail.com>
Date: Tue, 14 Jun 2005 09:22:02 -0600
From: Jeremiah Johnson <mrtidy@gmail.com>
Reply-To: Jeremiah Johnson <mrtidy@gmail.com>
To: richfeit@gmail.com, beehive-dev@incubator.apache.org
Subject: RE: Page Flow multipart request handling
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I think that it would be ideal for Jpf.Controller to support the
multipart class and then any options required by the multipart handler
implementation.  It doesn't seem like that is realistic to hope for
since it hasn't been done already.  Second to full configuration via
Jpf.Controller, in my mind, would be for beehive-netui-config to
contain the multipart defaults for the Web app and then override those
settings via the Struts config; this would leave Jpf.Controller to the
role of just turning config on or off.

Right now, beehive-netui-config only contains the disabled, memory,
and disk options.  Based on your previous comments, I assumed that you
were going to change the style in beehive-netui-config to specify the
multipart class and the full options.  If you are going to just keep
the three options forever, then I agree that you may as well keep the
same options in Jpf.Controller.

- jeremiah=20

> -----Original Message-----
> From: Rich Feit [mailto:richfeit@gmail.com]
> Sent: Monday, June 13, 2005 2:58 PM
> To: Beehive Developers
> Cc: Jeremiah Johnson
> Subject: Re: Page Flow multipart request handling
>=20
> Here's how I feel about this after thinking about the issue over the
> weekend (and after reading your response):
>=20
> There is one major setting in beehive-netui-config.xml for configuring
> multipart handing, and this setting contains three options:
>     - disabled
>     - memory
>     - disk
>=20
> There's also a major setting per-pageflow, within @Jpf.Controller.  I'd
> originally argued for making this a simple boolean, but given that this
> *overrides* the value in beehive-netui-config (<multipart-handler>), I
> feel now that it would be cleaner and more understandable to keep the
> same exact major options in the two places (and to have the value in
> @Jpf.Controller continue to override the value in <multipart-handler>).
>=20
> It sounds like we agree on keeping the more detailed configuration
> settings in beehive-netui-config.xml, so the only thing to hash out is
> whether to include all the same major options between
> beehive-netui-config.xml and @Jpf.Controller.
>=20
> Rich
>=20
>=20
> Jeremiah Johnson wrote:
>=20
> >It seems to me that overriding the configuration per page flow would be
> >a mighty rare occurrence, so I agree with your first point.
> >
> >I like your second point - to change the multipartHandler to just
> >enabled / disabled.  I initially thought that the change would be
> >useless, but since I agree that most webapps will have a single
> >multipart configuration it seems to follow that a page flow would just
> >turn it on or leave it disabled.
> >
> >- jeremiah
> >
> >
> >
> >>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
> >>
> >>
> >
> >
> >
> >
> >