I would :
1)Test with other DBCS based languages Cyrillic, Arabic, Hebrew, Mandarin
If all tests pass refactored
org.apache.pluto.util.PrintWriterServletOutputStream
2)run it thru Struts portlet archetype
- change directory to where the portlet template is to be created,
for example, a 'projects' directory (which you may need to create):
cd /home/projects
- run the following command to generate the sample PORTLET TEMPLATE assuming :-
- root java package -> com.myCompany.myPortlet
- the portlet war name -> myWebApp
--create the Portlet Project
mvn archetype:create -DgroupId=com.myCompany.myPortlet \
-DartifactId=myWebApp \
-DarchetypeGroupId=org.apache.struts \
-DarchetypeArtifactId=struts2-archetype-portlet \
-DarchetypeVersion=2.0.9-SNAPSHOT \
-DremoteRepositories=http://people.apache.org/maven-snapshot-repository
- to compile, execute
mvn compile
- to run test cases execute
mvn test
/*- to clean execute */
/* mvn clean */
- to package execute
mvn package
- to start it with jetty execute as a servlet
mvn jetty:run
I wouldnt realistically expect any of this to be done before the New Year but
if you could verify you can
create template
create Portlet Project
build with out errors or warnings
run thru aforementioned test cases
package
deploy to jetty
test on jetty
Then you'll have a 100% tested Pluto Portal Refactoring
Thanks!
Martin --
Date: Thu, 26 Dec 2013 12:25:49 +0530
Subject: Pluto doesn't support character encoding !!
From: [email protected]
To: [email protected]
Hi Pluto Team,
Background:
We are developing an application using Pluto v1.0.7 with Struts
v2.0.9 MVC.
Problem Description:
Adding a business name with Greek characters ‘Αυτόείναιμιαδοκιμή’ is rendered
as ‘Αυτόείναιμιαδοκιμή’
Root Cause:
Our Portlet is executing in render phase and we found that it doesn’t supports
the character set encoding option. Other Portlet execution (like ‘event phase’
& ‘regular servlet result’) do support character set encoding. Portlet those
are executing in render phase uses ‘RenderResponse’ (RenderResponseImpl) object
which implicitly uses PrintWriterServletOutputStream object which don’t
consider character set encoding specified with the configuration.
Solution:
To get the expected result we have modified
‘org.apache.pluto.util.PrintWriterServletOutputStream’ as below, reference:
public void write(byte[] pBuf, int pOffset, int pLength)
throws IOException {
String strValue = null;
if(characterEncoding != null && !"".equals(characterEncoding)) {
strValue = new String(pBuf, pOffset, pLength, characterEncoding);
}
if(strValue == null) {
strValue = new String(pBuf, pOffset, pLength);
}
mPrintWriter.write(strValue);
}
PS:
Below are the list of configuration which we used to specify the character set
encoding which don’t help us hence we modified the
PrintWriterServletOutputStream class to support specified character sets. See
the attachment for the same suggestion.
