Re: Cannot specify output character set for Pluto container

[Nick Lothian <nl...@essential.com.au>]

Are there any specific objections to this patch?

It appears to be a pretty clean way of getting a reasonable amount of
additional functionality. 

Nick

> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: Tuesday, 24 February 2004 11:15 AM
> To: pluto-dev@jakarta.apache.org
> Subject: DO NOT REPLY [Bug 26586] -Cannot specify output character set
> for Pluto container
> Importance: Low
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26586>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26586
> 
> Cannot specify output character set for Pluto container
> 
> 
> 
> 
> 
> ------- Additional Comments From 
> westbay@users.sourceforge.net  2004-02-24 00:45 -------
> There was a request for more information on how to use this, so:
> 
> After applying the patch, rebuild and redeploy the pluto context.
> 
> Open $TOMCAT_HOME/webapps/pluto/WEB-INF/web.xml and modify 
> the driver's servlet
> parameters as follows:
> 
>     <servlet>
>         <servlet-name>pluto</servlet-name>
>         <display-name>Pluto Driver</display-name>
>         
> <servlet-class>org.apache.pluto.portalImpl.Servlet</servlet-class>
>         <init-param>
>             <param-name>charset</param-name>
>             <param-value>utf-8</param-value>
>         </init-param>
>     </servlet>
> 
> A charset of utf-8 will allow you to mix native encodings, 
> such as allowing
> Chinese, Japanese, and Korean output all on the same portal.  
> If your portal
> only needs to support a single non latin-1 character set, you 
> can set it
> appropriately without any trouble.
> 
> There has been a request for the patch to be as an 
> attachement, so I'll submit
> it as such below.
> 
> I've gotten a lot of encouragement from people outside of 
> North America about
> this patch.  Most of us don't understand why this 
> functionality isn't there to
> begin with, as not being able to test portlets in native 
> languages is a huge
> barrier to adoptation.
> 
> The reason given for not supporting non latin-1 character 
> sets was that Pluto
> ONLY supports functionality that is labeled as a MUST in the 
> TCK (Technology
> Compatibility Kit).  While there are no TCK assertions 
> dealing with section 21
> (where locales are mentioned in the specification), there are 
> no assertions for
> logging either.  Yet logging is viewed as important enough to 
> rework multiple
> classes, adding external dependencies.  To add non latin-1 
> support adds no
> external dependencies and only involves a single file.  
> (Well, it would be nice
> to patch web.xml, too, with some comments.)
> 
> This patch, or something similar, *is* necessary to 
> non-native English speakers
> to get their portlets tested.  To the many who have cut and 
> pasted this patch
> into their own systems, this is more important than logging.  
> I hope the keepers
> of this project will reconsider their stance with regard to
> internationalization.  If this patch is unacceptable, then 
> how may I go about
> adding non latin-1 support in a proper manner?
>