[Fwd: Re: Page Flow multipart request handling]

[Rich Feit <ri...@gmail.com>]

In case anyone's been following this thread and is as confused as I 
was... somehow another copy of a several-days-old message from Jeremiah 
got re-sent to the list, after other discussion had taken place.  So he 
didn't miss my previous replies; rather, I failed to recognize that I 
was responding to the same message I'd already replied to last week.  :S

Rich

-------- Original Message --------
Subject: 	Re: Page Flow multipart request handling
Date: 	Sun, 19 Jun 2005 18:33:07 -0600
From: 	Rich Feit <ri...@gmail.com>
To: 	Beehive Developers <be...@incubator.apache.org>
CC: 	mrtidy@gmail.com
References: 	<55...@mail.gmail.com>



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
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>
>>>      
>>>
>
>  
>