DO NOT REPLY [Bug 26586] New: - 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

           Summary: Cannot specify output character set for Pluto container
           Product: Pluto
           Version: Current CVS
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: portal driver
        AssignedTo: pluto-dev@jakarta.apache.org
        ReportedBy: westbay@users.sourceforge.net


I've tried a number of methods to set the reply stream to UTF-8, including
having a Filter set the reply's locale and contentType.

Using a filter to set the locale to, e.g., java.util.Locale.JAPAN, returning
Japanese strings does work correctly (output is converted to Shift_JIS
encoding), but the portlet windows' decorations and controls (min, max, etc.)
disappear.  Therefore, this is not an acceptable work around.

Using a filter to set the reply content type to "text/html; charset=UTF-8",
while properly returning Japanese strings as above, also drops all portlet
windows' decorations and controls.  This also fails as a work around.

I also tried a number of other things with no effect, such as setting the
RenderResponse's content type to "text/html; charset=UTF-8" (looking at the code
I see that the charset is stripped) and setting the supports/mime-type value
similarly in portlet.xml.

After searching for where the Servlet's content type is set, I found that it was
only in portal/src/java/org/apache/pluto/portalImpl/Servlet.java, the first line
of doGet(...) to be specific.  Modifying this to set the response's character
set both allowed non ISO-8859-1 characters to pass to the client without being
converted to "?" and did not cause the decorations/controls on the portlet
windows to be dropped.

To allow end users to use this as an option init-param in web.xml, I modified
the Servlet.java code as follows (diff -u).

Index: portal/src/java/org/apache/pluto/portalImpl/Servlet.java
===================================================================
RCS file:
/home/cvspublic/jakarta-pluto/portal/src/java/org/apache/pluto/portalImpl/Servlet.java,v
retrieving revision 1.2
diff -u -r1.2 Servlet.java
--- portal/src/java/org/apache/pluto/portalImpl/Servlet.java    20 Jan
2004 09:30:10 -0000      1.2
+++ portal/src/java/org/apache/pluto/portalImpl/Servlet.java    30 Jan
2004 01:38:22 -0000
@@ -100,6 +100,11 @@
     {
         super.init (config);

+       String charset = config.getInitParameter("charset");
+       if (charset != null && charset.length() > 0) {
+               CONTENT_TYPE = "text/html; charset=" + charset;
+       }
+
         try
         {
             ServiceManager.init (config);
@@ -179,7 +184,7 @@
     public void doGet (HttpServletRequest servletRequest,
                              HttpServletResponse servletResponse)
throws IOException, ServletException
     {
-        servletResponse.setContentType("text/html");
+        servletResponse.setContentType(CONTENT_TYPE);

         PortalEnvironment env =
             new PortalEnvironment(servletRequest,
@@ -242,5 +247,7 @@


     private static boolean IS_DEBUG_ENABLED;
+
+    private static String CONTENT_TYPE = "text/html";

 }