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=31201>. 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=31201 Encoding bug when using <jsp:include ...> action ------- Additional Comments From [EMAIL PROTECTED] 2004-10-07 21:33 ------- I am still not happy with the portability implications of this. I still think it would be better for the 'fix' to be part of the application (and hence be portable) rather than part of the container (not portable and may require changes to app between containers depending on how each handles this). That being said, if all other options are inappropriate then I am prepared to consider this patch. Therefore I'd would appreciate it you would consider the following options. 1. I understand that some developers want to include HTML directly. However, given that this has i18n problems and i18n is obviously important to you why not tell your developers that they can't do this and should convert to JSPs? It is a change to the file name, adding a encoding directive and changing references from xxx.html to xxx.jsp. This would be trivial to automate. 2. How about using -Dfile.encoding="..." at the JVM level? 3. The patch (and option 2 above) assumes that every file has the same encoding. Is this always the case? Might different files in different apps have different encodings? If so, you could specify a modified version of the default servlet in your web application to handle .html files. With this option you could even handle different static file encodings within the same web app. This option would give you a lot of flexibility (which may or may not be useful to you). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
