[How To] - Handle Unicode contents obtained using PrimeFaces

At times, when you try to persist Unicode contents (e.g. Chinese characters), that are obtained using PrimeFaces's components, to the database and read back, you will see tons of question marks on your browser. For a detailed discussion on the root cause of this problem, please refer to the following answer of BalusC on StackOverflow.

To fix this issue, you need to make the following changes:

• Add these 2 properties to your JDBC connection.

• Re-configure the server to use UTF-8 instead of ISO-8859-1 as default coding. Using GlassFish, you simply need to add the following line to your project's glassfish-web.xml file:

Note: To have a better understanding of how to properly handle Unicode characters in JSF, please refer to the following article by BalusC: Unicode - How to get the character right?

[How To] - Fix Flash player cover other components

At times, you may run into a situation in which some components of your page get buried under the Flash player as following:

This is a well-known z-index issue caused by the Flash player. In brief, instead of being rendered within the browser, the Flash player is rendered in a new window (a bit like an i-frame) that is put on top of your browser. Because of this weird rendering, the Flash player will always stay on top of other components on your pages.

Luckily, the solution to this problem is pretty simple :). You simply need to set the wmode parameter of the Flash player to opaque.

With JSF and PrimeFaces's p:media component, you can easily achieve the above goal as following:

[How To] - Make non-secure cookie default for all kinds of connection

In a JavaEE application, JSESSIONID cookies' cookieSecure property can have one of the following values:

- true: All JSESSIONID cookies created by the container on behalf of the web application will be marked as secure.
- false: All JSESSIONID cookies created by the container on behalf of the web application will be marked as non-secure.
- dynamic (default):  A JSESSIONID cookie created by the container on behalf of the web application will inherit its security setting from the request that initiated the correspoding session: If the session was initiated by an HTTPS request, its JSESSIONID cookie will be marked as secure, and will remain non-secure otherwise.

Since the default value is dynamic, if the 1st page a user goes to is a HTTPS page (e.g. Login page), the cookie given to the user will be marked as secure. As a result, in many cases, subsequent non-secure HTTP pages may not be able to use the obtained cookie and thus, the user would be asked to log in one more time.

To overcome this issue, one way is to override the cookieSecure property's default value and change it to false. You can achieve this goal by updating the glassfish-web.xml file to include the following lines:



Note:

1. If cookie settings are defined declaratively in the web.xml file, the cookie properties defined here will take precedence.
2. If cookie settings are defined programmatically using javax.servlet.SessionCookieConfig methods, those cookie settings will take precedence over the cookie properties defined here.

[How To] - Fix "Offending RSA key" error

Occasionally, when you try to SSH to some server, you may run into the following Offending RSA key error:

To fix this issue, you simply need to edit the file ~/.ssh/known_hosts and remove the particular line that caused the error. In the above example, the following line is crucial:

It means that the offending key is in line 10 of the known_hosts file. So just open the file, delete everything on line 10, save the file and you're done :). 

Try the SSH command again! Everything should be working normally now.