beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Rohrlich" <rohrl...@bea.com>
Subject RE: Page Flow multipart request handling
Date Tue, 14 Jun 2005 18:32:39 GMT
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

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

--------------------------------------------------------------------------------

Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique online 
event, giving you the first look at a new category of enterprise software 
built specifically for Service-Oriented Architecture (SOA).

Register Now.  It's Free!

http://www.bea.com/events/june15

Mime
View raw message