DO NOT REPLY [Bug 26586] - Cannot specify output character set for Pluto container

[bu...@apache.org]

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?