DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34436>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34436 ------- Additional Comments From [EMAIL PROTECTED] 2005-04-13 18:33 ------- Martin, Now, I am confused: The javadoc for FileUploadBase.setHeaderEncoding() says: /** * Specifies the character encoding to be used when reading the headers of * individual parts. When not specified, or <code>null</code>, the platform * default encoding is used. * * @param encoding The encoding used to read part headers. */ so to me, it appears that this is complementary to what I am proposing: In fact, I see that struts as I am using it in org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest does call your setHeaderEncoding(), but it turns out that (be it struts' or the browser's fault) arrives as null. So, this is exactly the case where I want to avoid it being set to the system's file.encoding. Short from patching struts, I do not see an option where I as an application programmer who neither wants to touch the the struts nor the fileupload jar, can call your setHeaderEncoding() before it's already set to the platform encoding. So, what is probably needed that the FileUpload has an init() that creates a singleton per web-application for the headerEncodingDefault and the user can set that to a different value BEFORE e.g. struts or other frameworks start to use the FileUploadBase - what do you think? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
