Prog how-to

Did you get this error?

javax.faces.FacesException: Faces context not found. getResponseWriter will fail. Check if the FacesServlet has been initialized at all in your web.xml configuration fileand if you are accessing your jsf-pages through the correct mapping. E.g.: if your FacesServlet is mapped to *.jsf (with the <servlet-mapping>-element), you need to access your pages as ’sample.jsf’. If you tried to access ’sample.jsp’, you’d get this error-message.
javax.faces.webapp.UIComponentTag.setupResponseWriter(UIComponentTag.java:926)
javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:313)
org.apache.myfaces.taglib.core.ViewTag.doStartTag(ViewTag.java:73)
org.apache.jsp.list_jsp._jspx_meth_f_005fview_005f0(list_jsp.java:161)

There are a couple of reasons the error appears.

First situation

The first one is explained in the error itself – at least with this implementation(Apache MyFaces). So, in some Java web containers, notably Tomcat, first time when you access a JSF resource (a jsp page that contains the f:view and other JSF components) you need to access it using the url patter declared in the web.xml for the Java Server Faces servlet. It is usually *.jsf or *.faces – so instead of putting whatever.jsp, you use whatever.faces. Then, the faces context is created and the application will run fine. Usually the jsf applications starts by setting a welcome page that only forwards to a genuine JSF url – ex: index.jsp only has a <jsp:forward page=”second.jsf” />

The other situation

Lets focus on the second situation: you have a JSF application that works just fine, and then after being left idle for some time, the session expires and then shows the above error message.

The reason: the JSF framework expects to find the faces context in the session. It does not find it, then will show this exception.

Now, any programmer provides a functionality in his / her application to deal with the expired session. Usually a tag is placed in each JSP at the very beginning, the tag would check the session object to see whether the user is still logged, and if not the application usually forwards to the login page showing in the same time an appropriate error message “The session expired please login again”.

The problem here is that the error from JSF takes precedence, meaning that the garbled error message will be shown on the screen rather than having the application behave as described in the previous paragraph.

How you can fix it:
The error triggered by JSF is a “HTTP error 500″ one, so you need to handle this at the application level, by inserting the follwing xml tags in the web.xml file:

<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>


Please make sure you defined error.jsp file in your application.

Very important: please make sure that error.jsp is a plain jsp and not a JSF one otherwise you did not fix anything.

From this point, you have options, either you show an error message and provide a link to the login page, or you directly forward to the login page and show the error message there.

The current article shows you how to move a private key between two JKS keystore files.

General
JKS keystores are binary files holding one or more keys in Java. The keys are used for SSL connectivity. There are two key types, private and public. The private key holds the site identity. The public key is generated from the private key and it is passed to the other party where it is installed in a special JKS keystore.

Most of the time, the keystore files are manipulated with a special Java tool called keytool. The tool can be found in the bin folder of the Java installation.

In order to move a key from a keystore file to the other, you need to export the key from the original keystore and import it in the second one.

Problem
When you use keytool with the export option on a private key, the tool does not extract the actual private key from the store (for security reasons). Only the public key is extracted.

That means you can’t use keytool for this operation.

Solution
There is a class in JDK called java.security.KeyStore. Keytool is implemented using this class functionality as well.

Given a JKS keystore file, we will write the code that will proceed through the following steps:

1. Open the keystore file
2. Load both the key and the keychain
3. Open another keystore
4. Save the loaded key in the keystore

First we assume we have two keystores, one is called first.jks and contains a private key under the alias first, and one called second.jks empty.

The full page code is here

And here is the result while listing the second keystore:

C:\temp\certs>keytool -list -storepass second -keystore second.jks

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

second, 10-Oct-2008, keyEntry,
Certificate fingerprint (MD5): 33:8A:A3:7C:9E:FD:31:39:17:A1:E4:F4:0D:3B:C1:8F