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 richfeit@gmail.com designates
 64.233.184.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:x-enigmail-supports:content-type:content-transfer-encoding;
        b=Louxq2KM5tAp/xYyRUwUAOEhZr0E8E7blwmCiJSZ9gBgLQUI9tj51RxiQRFVgkqPK+H41fiMOUwXbw+rsJk7Q4SzTTNyUm0JFKHhkaan/k+SlIFxbmGp6Kkn7WkuqkR+9FP3ZKbJmUm+At5YwoZSGdEYKZxmEu6as0LxEWrjBvo=
Message-ID: <42B60EC3.6050909@gmail.com>
Date: Sun, 19 Jun 2005 18:33:07 -0600
From: Rich Feit <richfeit@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Beehive Developers <beehive-dev@incubator.apache.org>
CC: mrtidy@gmail.com
Subject: Re: Page Flow multipart request handling
References: <55c1942005061408222bd9986f@mail.gmail.com>
In-Reply-To: <55c1942005061408222bd9986f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jeremiah,

I (still) agree with you.  :)  Sounds like you might have missed my 
previous responses -- here's the end of the thread (after the part you 
quoted below):

> OK, thanks for the feedback.  Sounds like the consensus is that it's 
> best to keep options consistent between beehive-netui-config.xml and 
> @Jpf.Controller.  I'm going to fix the original JIRA issue 
> (http://issues.apache.org/jira/browse/BEEHIVE-802 ) by changing our 
> code to avoid using DiskMultipartRequestHandler.  I've entered an 
> enhancement request for the rest of the work: 
> http://issues.apache.org/jira/browse/BEEHIVE-818 .
>
> Rich
>
> John Rohrlich wrote:
>
> Turning off multipart in beehive-netui-config and turning it on for a
> specific page flow is a reasonable use case to support.  More generally
> I'd say it is good to have the same options in @Jpf.Controller and
> beehive-netui-config.xml. The alternative, turning on multipart in the
> page flow and configuring multipart with struts merge, is less clean and
> certainly less obvious.
>
> john
> -----Original Message-----
> From: Rich Feit [mailto:richfeit@gmail.com] Sent: Tuesday, June 14, 
> 2005 9:47 AM
> To: Beehive Developers
> Cc: Jeremiah Johnson
> Subject: Re: Page Flow multipart request handling
>
> I can see the argument for @Jpf.Controller supporting all the options 
> (including the multipart handler class), especially for cases when 
> multipart handling is disabled by default in 
> beehive-netui-config.xml.  The two methods for configuration 
> (beehive-netui-config.xml and @Jpf.Controller) would then be in sync 
> across the board, with @Jpf.Controller overriding the XML settings.  
> I'd be inclined to do it.
>
> Any other thoughts on this?
>
> Rich

Rich

Jeremiah Johnson wrote:

>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 
>
>  
>
>>-----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
>>
>>Here's how I feel about this after thinking about the issue over the
>>weekend (and after reading your response):
>>
>>There is one major setting in beehive-netui-config.xml for configuring
>>multipart handing, and this setting contains three options:
>>    - disabled
>>    - memory
>>    - disk
>>
>>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>).
>>
>>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.
>>
>>Rich
>>
>>
>>Jeremiah Johnson wrote:
>>
>>    
>>
>>>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
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>
>>>      
>>>
>
>  
>