Deploying JSF application on a Glassfish cluster

1
votes

When I deploy a JSF application on a Glassfish V2.1 Patch02 Cluster, the following exception is thrown while loading the first page.

java.security.ProviderException: update() failed
    at  sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:557)
    at  sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:457)
    at  sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:485)
    at  sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:471)
    at  javax.crypto.Cipher.doFinal(DashoA13*..)
...
Caused  by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DEVICE_ERROR
    at  sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
    at  sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:510)

I am NOT using any kind of encryption/decryption inside my application.

When I googled up for this exception, I found this which is the case when Ciphers are loaded in the application.

I would like to know if Glassfish/JSF load default Ciphers which are causing this exception?

If not, what could be the possible cause and the solution for it?

3
deploymentjsfjakarta-eeglassfish

3 Answers

1
votes

The issue has been resolved. The problem is this 'minor' bug - https://issues.apache.org/jira/browse/MYFACES-1786

The solution is to put the following entries in the web.xml to disable encryption for state management and to switch the state saving to server

<context-param>
        <param-name>org.apache.myfaces.USE_ENCRYPTION</param-name>
        <param-value>false</param-value>
</context-param> 

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>server</param-value>
</context-param>

From my experience the application when deployed with encryption enabled by 'default' (i.e. having no entry for org.apache.myfaces.USE_ENCRYPTION in web.xml) in Websphere(standalone or cluster) works perfectly okay.

But the application does NOT get deployed in Glassfish cluster or in Tomcat 6 (the problem is defined in the thread - nabble.com/BadPadding-Exception-and-more-td21984713.html)

0
votes

The only place I can think where the base JSF implementation might use encryption is in state management. The component tree is stateful, so it is preserved between requests, either in the session or in a hidden form field (set by the javax.faces.STATE_SAVING_METHOD init parameter). If a hidden form field is used, the implementation would be wise to encrypt it to prevent hackers rewriting server state. (Note that state management in JSF is pluggable, so 3rd party libraries could replace the default behaviour. If you're using a rich component library, it's worth checking the doc.)

0
votes

You could try deploying your app in non-clustered glassfish, or in tomcat and see if you get the same situation. Then you would know if the problem is your app or the configuration of the app server or cluster.