• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Encoding problems in JSF

 
Ranch Hand
Posts: 74
5
Eclipse IDE Python Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all!

I'm new to JSF and I'm facing a problem with displaying German umlauts correctly.

I have built a site that uses an inputText to submit text that will be displayed in a list of paragraphs (as simple html... <li><p>text</p></li> etc.). A managed bean is used as a controller to store data in backend and to retrieve it from backend for display. In backend the data is stored in a list of strings and using annotations this data is written to respectively read from file system on shutdown/startup via serialization. Sometimes when I'm sending German umlauts from my webbrowser they're not displayed correctly, other times however they are which is pretty weird to me.

I've built the project with NetBeans 8 and I made sure that under Properties -> Sources the Encoding is set to UTF-8. In the xhtml page for display the encoding is set as follwed:

<?xml version="1.0" encoding="UTF-8"?> //first line
<meta http-equiv="content-type" content="text/html; charset=utf-8"/> //in the head
<h:form [...] acceptcharset="UTF-8"> //all forms surrounding the inputText and the paragaraph list

I'm developing on a Ubuntu 14.04 desktop. For deployment I transfer the .war file via ssh to my server which is Ubuntu server (currently not sure which version, might be 12) and there I deploy the .war file on my Glassfish server online.

An example of how the input appears when it's incorrectly displayed: ä
The same letter appears like this when it's correctly displayed: ä

Another example, incorrect: ö
correct: ö

Once the data is input its appearance won't change anymore so I assume the incorrect encoding happens already before the data is stored in backend. I'm not sure yet under which conditions the data is displayed incorrectly. Let me know which other information you need. Thanks!
 
Saloon Keeper
Posts: 28482
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just to be properly Prussian about things, I must point out that a JSF managed/backing bean is not a Controller in the MVC sense, it's the Model. Action methods in managed beans are external to MVC and are basically business methods. A true Controller's sole function is to synchronize values between Model and View and not do any business/persistance functions, and in JSF, the Controllers are all pre-supplied - you only code Models and Views.

However, that's immaterial to your problem, just being meticulous.

My suspicion is that you haven't got your persistent storage in correspondence with the I18N used in your JSF application. Databases also have Code Pages and I've had issues more than once where part of a system was in UTF-8 but the backend was set to ISO-8990-1 (or some such).
 
Peter Muster
Ranch Hand
Posts: 74
5
Eclipse IDE Python Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Just to be properly Prussian about things, I must point out that a JSF managed/backing bean is not a Controller in the MVC sense, it's the Model. Action methods in managed beans are external to MVC and are basically business methods. A true Controller's sole function is to synchronize values between Model and View and not do any business/persistance functions, and in JSF, the Controllers are all pre-supplied - you only code Models and Views.

However, that's immaterial to your problem, just being meticulous.

My suspicion is that you haven't got your persistent storage in correspondence with the I18N used in your JSF application. Databases also have Code Pages and I've had issues more than once where part of a system was in UTF-8 but the backend was set to ISO-8990-1 (or some such).


Thanks for the input.

I suspect what might be reason for the encoding problem. I have the site in my browser in a pinned state so it's always open. Even though I've reloaded the site with CTRL+F5 after my last update to it which added the meta tag specifying the encoding it does apparently still have the outdated site when I restart the browser so the first time I post the data will be displayed incorrectly. Every following post as long as my web browser is kept open will send the encoding correctly though.
I've reset the "cached files and images" in my Chromium browser and this seems to have fixed the problem. Now I still need to check how my friend can reset the cache in his android web browser. If that works it'll have confirmed my assumption. I find it unusual though that Chromium still used an outdated cached file on start up of the browser and after the first post used an up to date version but if that was the reason I'll be happy.

To respond to your comment directly: Controller is probably the wrong term. My site is very flat and has neither business layer nor a real persistence layer (I intended to keep it as simple as possible). The persistance "layer" is actually integrated in the back end model. With controller I meant the object that is transferring information between the end user (xhtml page) and the backend. My backend is a ManagedBean is as well which is ApplicationScoped. This bean keeps the content in an ArrayList<String> which is written to/read from file system on shutdown/startup. I have no encoding specified there and as the serialization only happens when the web application server is stopped I don't think it could have anything to do with the encoding problem. Now before further assumptions are made: I've written this site to conveniently arrange fitness center sessions with a friend which we do multiple times per week and I wanted to do it in an easily accessible way (also from mobile devices) and outside of any social platforms. The data stored is therefore not anyhow critical and if in worst case conversation is lost due to an unexpected crash of my web application server it's not a big deal to me unless it proves to happen regularly (and before any comments are made this site is not public and secured by measures I deem adequate for it).

I'll post an update to this thread later if my suspicion is confirmed. P.S.: If anyone has a clue why my web browser uses an outdated cached version on start up but after the first refresh uses the up to date version I'll be happy to know about it.
 
Peter Muster
Ranch Hand
Posts: 74
5
Eclipse IDE Python Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay unfortunately I cannot confirm that clearing the cache solved the issue. The problem appeared this morning again. Strangely though only the first time I submitted text. I tried it with the same Umlaut again afterwards and it was displayed correctly.
 
Peter Muster
Ranch Hand
Posts: 74
5
Eclipse IDE Python Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Anyone else an idea what could cause this? This is driving me mad... :-( I'm usually getting the encoding issue when inputting text for the first time (after I have closed my web browser for a long while / have just started up my notebook). After the first post everything is fine until I close the browser and write again a few hours later. I've also added the following meta content to make sure it's not a caching issue:

<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="pragma" content="no-cache" />
<meta http-equiv="expires" content="0" />

Any input is appreciated, I have no idea how to debug this further.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic