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 >>> arbitrary? >>> >>> 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 >> 3.1.3). > > 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 problem. If it's just using getInputStream(), then it will just go away. -- Scott > >> 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 > entails. > > Thanks, > > Aaron Freeman > > > > _______________________________________________ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
