Just to clarify... By "scrapping MultipartDecoder.setSizeMax()" I just mean dropping the method from the interface. The implementation class still needs a mutator method so that the maxSize property can be set via the hivemind descriptor.
Thanks for all the hard work, Jesse.
Paul
Jesse Kuhnert wrote:
> Agreed.
>
> The sizeMax naming was used because that's what commons-fileupload was
> doing. I agree that maxSize is a better name though.
>
> On 3/21/06, Paul Ferraro <[EMAIL PROTECTED]> wrote:
>
>> I think the dev list is a probably more appropriate/efficient location
>> for the remainder of this discussion...
>> I agree with everything except "allowing it to accept it or not
>> depending on whether or not someone has manually configured it to be a
>> global value."
>>
>> I think we should scrap the _sizeMaxSet and
>> MultipartDecoder.setSizeMax() logic altogether.
>> I do agree with the first part though. Something like this perhaps?
>>
>> MultipartDecoderImpl:
>> public HttpServletRequest decode(HttpServletRequest request, Long
>> maxSize)
>> {
>> // ...
>> ServletFileUpload upload = createFileUpload(maxSize);
>> // ...
>> }
>>
>> private ServletFileUpload createFileUpload(Long maxSize)
>> {
>> // ...
>> upload.setMaxSize((maxSize != null) ? maxSize.longValue() :
>> _sizeMax);
>> // ...
>> }
>>
>> One last thing... can we rename sizeMax to maxSize?
>>
>> Thoughts?
>>
>> Paul
>>
>> Jesse Kuhnert (JIRA) wrote:
>>
>>> [
>>>
>> http://issues.apache.org/jira/browse/TAPESTRY-368?page=comments#action_12371297]
>>
>>> Jesse Kuhnert commented on TAPESTRY-368:
>>> ----------------------------------------
>>>
>>> Ok, a plausible solution....
>>>
>>> Change the Upload component's maxSize parameter to be an Integer object,
>>>
>> so that we can tell if it's actually been set or not, and don't give it a
>> default value. (Allow the MultipartDecoder service to handle that).
>>
>>> Then, as previously mentioned, pass the parameter in to the Decoder
>>>
>> service, allowing it to accept it or not depending on whether or not someone
>> has manually configured it to be a global value.
>>
>>> Does this sound workable?
>>>
>>>
>>>
>>>> Please add setMaxSize to MultipartDecoder
>>>> -----------------------------------------
>>>>
>>>> Key: TAPESTRY-368
>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-368
>>>> Project: Tapestry
>>>> Type: New Feature
>>>> Components: Framework
>>>> Versions: 4.0
>>>> Reporter: Gavin Mathias
>>>> Assignee: Jesse Kuhnert
>>>> Priority: Minor
>>>> Fix For: 4.0.1
>>>> Attachments: tap368.txt
>>>>
>>>> I use the Upload component to upload files to my application. Most of
>>>>
>> those files are over the size limit of 10000000 hardcoded in
>> MultipartDecoderImpl. Please add setMaxSize(int _maxsize) to
>> MultipartDecoder so that I can write a custom Upload component that can do
>> this:
>>
>>>> getDecoder().setMaxSize(30000000);
>>>> Even nicer would be a parameter in Tapestry's Upload.jwc that can be
>>>>
>> used to set MaxSize.
>>
>>>> I was doing this in Tapestry3.0.3 by calling:
>>>> DefaultMultipartDecoder.getSharedInstance().setMaxSize(30000000);
>>>> in my custom component's page class.
>>>> Thanks and Best Regards,
>>>> Gavin
>>>>
>>>>
>>>
>>
>>
>>
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://opennotion.com
>
>
smime.p7s
Description: S/MIME Cryptographic Signature
