On Aug 13, 2007, at 11:20 AM, Aaron Freeman wrote:
>>> I see from your link that Sun uses an int, but couldn't that be
>>> I don't believe Jakarta, and other implementations have this limit
>>> -- I just
>>> looked and they are using a long. This is a seriously
>> limiting factor
>>> and may require us to swap out our underlying servers from Resin
>>> (which I really, really don't want to do).
>> The HttpServletRequest.getContentLength() will still return
>> int, but Resin will be able to use a long value internally (in
> Ok so this problem will "just go away" with version 3.1.3 or it
> will require
> some special calls somewhere?
It depends. If the application code is using
HttpServletRequest.getContentLength(), then you will still have a
If it's just using getInputStream(), then it will just go away.
>> However, you could also use chunked-encoding for your uploads
>> (assuming you have control over your client). That would
>> avoid the 32- bit issue entirely.
> Let me check with the developer of the client and see what this
> Aaron Freeman
> resin-interest mailing list
resin-interest mailing list