resurrecting an oldish thread...
Daniel, can you enlighten me on why you ended up solving this in the VelocityServlet the way you did? i want to port this fix over to the VelocityViewServlet, but i gotta admit your solution looks ugly to me.
Sure! Would you be more specific about what "looks ugly"? If you're referring to the string manipulation, well, that's just how this sort of thing is done in servlet land:
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletResponse.html#setContentType(java.lang.String)
You'll note that ServletResponse has no setCharacterEncoding() method, and its header JavaDoc actually incidates that setContentType() should be used to do just that:
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletResponse.html
ServletResponse does (un-orthogonally) supply a getCharacterEncoding() method, which I do use.
When porting, please also note that rev 1.50 of VS included a forward-port of Bill Boland's fix for http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18951, so the corresponding code in VelocityViewServlet could possibly be dropped as it is now present in its super class.
i'm assuming there's good reason for it, but i can't quite figure it out. the solutions we'd discussed earlier in this thread still seem clearer to me.
Yeah, seemed like the best way to meet the goals and play nicely with the implementation/integration technologies. Here's a link to the change:
http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/src/java/org/apache/velocity/servlet/VelocityServlet.java.diff?r1=text&tr1=1.50&r2=text&tr2=1.52&diff_format=u
Output encoding is now determined on a per-request basis. This is essential for allowing dynamic selection of output encoding (e.g. Shift_JIS responses for "Accept-Language: ja" requests from Tetsuya, ISO-8859-1 responses for "Accept-Language: en-US" requests from Dan, etc.).
The API for setting the response encoding mirrors what is done by the Servlet API, which is the most appropriate interface for VelocityServlet. I've had the questionable honor of reviewing the related portion of Catalina's code quite a few times.
Here's relevant portions of the CVS change log from rev 1.51:
* src/java/org/apache/velocity/servlet/VelocityServlet.java encoding: Removed unnecessary class field.
init(): No longer set encoding field.
doRequest(): Moved call to requestCleanup() down into a finally block. This is a minor change in behavior to supply a much more useful cleanup hook for cases where unexpected exceptions are thrown.
mergeTemplate(): Get the character encoding from the HttpServletResponse object. The assumption is that it has already been set via a charset= parameter on the Content-Type header.
setContentType(), chooseCharacterEncoding(): Added support for dynamic selection of response character encoding.
Daniel Rall said:
"Nathan Bubna" <[EMAIL PROTECTED]> writes:
Daniel Rall said:
VelocityServlet doesn't currently support the ability to override the character encoding of its output on a per-request basis. Instead, it's hard-wired to the single value from the configuratin of the RuntimeSingleton. For I18N'd applications, this is painful. The pain can be alleviated by inserting a hook method for determining the output character encoding to use on a per-request basis.
makes sense to me. and, of course, such a change should be mirrored in
the
VelocityViewServlet.
Okay.
...
Though this a backwards incompatible change, I estimate that in 85% of use cases this change will be transparent, as a Latin-1 encoding (e.g. ISO-8859-1) will generally already be in use.
why not create it with a deprecation/migration path? e.g.
I've always been a fan of getting that as Right as possible. =)
during init, do:
encoding = RuntimeSingleton.getString(RuntimeSingleton.OUTPUT_ENCODING);
and in mergeTemplate, get the encoding from this method:
protected String getCharacterEncoding(Context context, HttpServletResponse response) { if (encoding == null) { String enc = response.getCharacterEncoding(); if (enc == null) { enc = DEFAULT_OUTPUT_ENCODING; } return enc; } return encoding; }
this way, if they are specifying their encoding in the velocity.properties, it will still work.
"It" being the old behavior, yeah. However, I contend that the old behavior is somewhat broken (especially for dynamic I18N'd applications), and thus think that we should move away from it.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
