[JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems in Wildfly

Friday, 3 January 2014

    [
https://issues.jboss.org/browse/WFLY-2705?page=com.atlassian.jira.plugin....
] 

Andre Pankraz commented on WFLY-2705:
-------------------------------------

Thanks for the hint, the workaround to explitely use the CharacterEncodingFilter and
adding the CDI Filter behind this worked.

Strange that it works for JBoss 7.2 and Wildfly with AJAX though.
I hope there is a better solution in the future.
I found some hints to the new attribute <servlet-container  ...
default-encoding="UTF-8"> but my version (from git yesterday) didn't know
about it yet.
Thanks again!

...
 Unicode and Umlaut problems in Wildfly
 --------------------------------------

                 Key: WFLY-2705
                 URL: https://issues.jboss.org/browse/WFLY-2705
             Project: WildFly
          Issue Type: Bug
      Security Level: Public(Everyone can see) 
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
         Environment: CentOS
 java version "1.7.0_45"
 OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
            Reporter: Andre Pankraz
            Assignee: Jozef Hartinger

 I think I'm doing something wrong if this is really a CR1, but I cannot get UTF
working properly on Wildfly. (It works fine in same environment and same settings/code in 
jboss-as-7.2.0.Final.)
 * If i have an JSF inputText in a form (hence POST)
 * and I enter "TestÜÖÄ"
 * I get "TestÃ?Ã?Ã" as result.
 If I provide a <f:ajax render...> on this field, the ajax rendering creates the
proper response, but if I submit the data I always get the wrong encoded result.
 I created a minimalistic web app without any additional libs with just one JSF test page
(see below). It works in jboss as 7.2 final but not in Wildfly CR1.
 I have set in the environment:
   -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
 An encoding filter didn't help either.
 May be I'm doing something wrong here, but I have seen quite some other bugs that
don't really speak for a "Release-Candidate" so it might really be an issue?
Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version?
Will add some more reports.
 Example page for quick test:
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <f:view encoding="UTF-8"
xmlns:f="http://java.sun.com/jsf/core">
 	<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
 		xmlns:h="http://java.sun.com/jsf/html"
 		xmlns:ui="http://java.sun.com/jsf/facelets">
 <h:head>
 	<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" />
 	<title>Test</title>
 </h:head>
 <h:body>
 	<h1>Test ÜÄÖ</h1>
 	<h:form id="test">
 		<h:inputText label="Test: " value="#{test.test}">
 			<f:ajax render=":test" />
 		</h:inputText>
 		AJAX: #{test.test}
 		<br />
 		<h:commandButton action="#{test.print()}" value="Print" />
 	</h:form>
 </h:body>
 	</html>
 </f:view>
 package test;
 import javax.enterprise.context.RequestScoped;
 import javax.inject.Named;
 @Named
 @RequestScoped
 public class Test {
 	private String test;
 	public String getTest() {
 		return test;
 	}
 	public void setTest(String test) {
 		this.test = test;
 	}
 	public String print() {
 		System.out.println("TEST: " + getTest());
 		return "success";
 	}
 } 
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006