Details
Description
Problem Background:
This test is likely failing due to a lack of regional support for the iso-8859-16 character set in either the JVM from Oracle or the underlying operating system, which in this case is macOS Sonoma 14.1.1 (23B81). So the problem isn't with Pluto or the TCK really, it's more of an environment support problem. Switching to iso-8859-15 fixes the problem.
Steps to Reproduce:
- Visit http://localhost:8080/pluto/portal/V2AddlResponseTests
- Click on the "V2AddlResponseTests_SPEC2_12_Resource_characterEncoding2" link
Expected Results
The portlet displays the following:
Test Succeeded
Details: The character encoding can be set via the setLocale method and a locale-encoding-mapping-list mapping in the web.xml deployment descriptor
Actual Results
The tomcat console log report the following stack trace:
Caused by: java.nio.charset.UnsupportedCharsetException: iso-8859-16 at java.nio.charset.Charset.forName(Charset.java:531) at org.apache.tomcat.util.buf.CharsetCache.getCharset(CharsetCache.java:195) at org.apache.tomcat.util.buf.B2CConverter.getCharset(B2CConverter.java:63) at org.apache.coyote.Response.setCharacterEncoding(Response.java:498) at org.apache.catalina.connector.Response.setCharacterEncoding(Response.java:796) at org.apache.catalina.connector.ResponseFacade.setCharacterEncoding(ResponseFacade.java:460) at javax.servlet.ServletResponseWrapper.setCharacterEncoding(ServletResponseWrapper.java:84) at org.apache.pluto.driver.services.container.PortletResourceResponseContextImpl.setCharacterEncoding(PortletResourceResponseContextImpl.java:59) at org.apache.pluto.container.impl.ResourceResponseImpl.setCharacterEncoding(ResourceResponseImpl.java:126) at org.apache.pluto.container.impl.ResourceResponseImpl.setLocale(ResourceResponseImpl.java:164) at javax.portlet.tck.portlets.AddlResponseTests_SPEC2_12_Resource.serveResource(AddlResponseTests_SPEC2_12_Resource.java:287) ... 64 more