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?
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)
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.)
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.
Related
Pardon if I can't give more pointers, but I'm really a noob at wildfly. I'm using version 9.0.2.
I have deployed jbpm-console, drools, and dashboard - no problems here. I restart wildfly using the jboss CLI, and when I login again, the repositories won't appear in the web interface or on disk (atleast nothing that grepping or find will show).
I'm using the H2 database. I'm not even sure where to look, does anyone have any idea?
Thanks in advance!
After enough reading through the docs, it would seem that it's necessary to configure jBPM to persist. From the docs:
"By default, the engine does not save runtime data persistently. This means you can use the engine completely without persistence (so not even requiring an in memory database) if necessary, for example for performance reasons, or when you would like to manage persistence yourself. It is, however, possible to configure the engine to do use persistence by configuring it to do so. This usually requires adding the necessary dependencies, configuring a datasource and creating the engine with persistence configured."
https://docs.jboss.org/jbpm/v5.3/userguide/ch.core-persistence.html
As a security measure my organization requires me to validate a header attribute to allow a request to go through the business rules. Where would I need to configure this in the Jboss eap 6.3? This configuration was done before me and i am not sure how it was achieved before in the earlier jboss 5.x. Please let me know how would I configure the container security without making any application changes.
You could do this in a Global Valve, which is like a servlet filter but with more access to JBossWeb (Tomcat) internals and applies to all requests. Details are in the documentation at https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/chap-Global_Valves.html
That is not portable between containers, and will not work in WildFly or EAP 7+ since the web container has changed from JBossWeb to Undertow.
In my understanding, this has to be done in applications. Not sure if this can be done generally in JBoss configuration.
Try this https://www.owasp.org/index.php/How_to_add_validation_logic_to_HttpServletRequest
Turns out we had a different way of handling it. We used the single sign on feature of Jboss 5 and at the container level validated the header. When the header was validated, a generic role name was exposed which was used by Applications to limit the resources to the specific role name.
I am new to jboss and would like to know what are the differences between ServiceMBean and load-on-startup servlet tag in web.xml? Also, I would like to know which one will always get loaded first or they are loaded at the same time? In what situation, I should use MBean and when I should use startup servlet or it doesn't matter?
I need to write a a class/servlet to validate if all the required system properties (e.g -DINSTALL_DIR=blah ) is set. If not, then stop right there. else proceed and start the application.
Thanks in advance
-A
ServiceMBean is JMX, it is part of your JVM. load-on-startup servlet tag in web.xml is part of your J2EE application.
JMX is part of J2SE starting from JDK 1.5. So, you can have one ServiceMBean per JVM. not per application. JMX is used mostely for monitoring and managing the JVM. It provides access to information such as: number of classes loaded and threads running, memory consumption, garbage collection statistics, on-demand deadlock detection, and others. Another common use, is to refresh your cache.
JMX will allow you to instrument your application and control/monitor it using what-ever management console that your JMX container supports. An example would be a web application that implements a reference data cache...
A problem we had before was we would occasionally need to refresh the cache because a customer name changed in the database. If we had a refresh method on the MBean interface then we should be able to trigger this event using the JMX console. The JMX console may be a web or fat client that comes with our J2EE server. Our J2EE server may also support SNMP. This means that we may be able to invoke the method from a standard Tivoli or UniCenter console.
http://www.theserverside.com/news/1364664/J2EE-Application-Management-The-Power-of-JMX
You don't need remote access to ServiceMBean in order to trigger some asynchrious action. Moreover, you need validation on scope of application, not the whole JVM (while, you can, theoretically, handle this issue in the ServiceMBean). So, it is more naturally, to do it as load-on-startup servlet tag in web.xml. In this way, in every start up of your application validation will happen.
One more clarification: ServiceMBean is JBoss-way to write JMX. All MBeans are server wide (not application wide). That's why I use MBean and ServiceMBean freely above.
We have a GWT application which draws some resources from a separate servlet via async javascript. In production this poses no problems as both the producer servlet and the consumer GWT app will reside on the same server, however for development I can't find a way to make this happen as we are head to head with the Same Origin Policy.
As a temporary solution I have the servlet running on Tomcat, and I compile and deploy the GWT app to that same Tomcat instance - this of course works, and it does allow me to attach Eclipse for debugging. However there is the slight problem of the 40 second or so build time for each modification.
We would like to be able to debug via GWT's hosted mode w/ OOPHM - can anybody see a way for us to do this?
Thanks all!
you could use the -noserver option of gwt dev mode, which lets you run your server code with any servlet container.
Maybe you can deploy the producer servlet to Jetty.
http://www.enavigo.com/2008/08/29/deploying-a-web-application-to-jetty/
I think the Jetty home most reside somewhere in the Eclipse directories. A simple file search might help.
Good luck!
If you need just a servlet, why not define it in web.xml and start dev mode as usual?
I am trying to deploy my application (packed in .war file) that work properly on JBoss 4.2.3 to JBoss 5.1 (using java 5).
Currently during deployment time I see in the server.log the error:
... Caused by:
org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
...
Caused by:
java.lang.ClassCastException:
org.apache.xerces.parsers.XML11Configuration
According to this thread in JBoss forums, I need to isolate my application.
My questions:
according to JBoss 5.1 Release Notes - The major differences with the existing configurations is that call-by-value and deployment isolation are enabled by default. Therefore do I really need implicitly set my application isolated?
I thought that isolation is mainly needed when the same application server runs several applications that collides with each other. In my case I am trying to run only one application. So again is the isolation required?
If the answer is positive to the above question and I need to enforce isolation - how can I configure it? suppose my war file is called 'foo'. do I have to insert to the jboss-web.xml the section:
<jboss-web>
<loader-repository>
tld.mydomain:loader=foo.war
</loader-repository>
</jboss-web>
OK Apperently the solution is to remove xerces.jar from my web-inf/lib
Isolation won't work due to some bug. See here
Failed to create a new sax parser error is due to the availability of unwanted JAR files in WAR and EAR if there. So by deleting those unwanted JARS this error is been cleared.