Patching RichFaces 3.3.3 AJAX.js for IE9

There are always some problems when working with 3rd party frameworks when the world moves forward but the framework you’re using doesn’t. After JSF 2 was released the RichFaces development moved to 4.x version and they dropped support for the older versions although many users are still using the older versions as it’s not trivial or free to update to JSF 2 & RichFaces 4. Now if users have problems with the older versions they just have to patch it themselves as the RichFaces team isn’t going to fix e.g. the IE9 issues.

The problem with Internet Explorer 9 is that with RichFaces 3.3.3.Final the Ajax components doesn’t work and there are errors shown in the JavaScript Console. For example when testing RichFaces Ajax demos the JavaScript is assigning A.outerHTML = new XMLSerializer().serializeToString(C) which gives the following error:

SCRIPT16386: No such interface supported

Fortunately it’s relatively easy to fix it for IE9 by patching the AJAX.js JavaScript file in RichFaces. The process is discussed in RichFaces’s RF-9485 -JIRA ticket and JBoss forum message. In short the patching for AJAX.js contains following steps.

Update 2013-06-13: If you want quick solutions and aren’t interested about how it’s done, you can get the patched AJAX.js from the RF-9485 ticket as Ken Clubok pointed out in the comments.

Upgrading Sarissa Framework and patching RichFaces AJAX.js file

Resources:

1) Instead of patching Sarissa as suggested in the ticket it’s better to upgrade Sarissa to 0.9.9.6 as it has some additional IE9 issues fixed.

Download Sarissa:
http://sourceforge.net/projects/sarissa/files/sarissa/Sarissa%200.9.9.6/sarissa-0.9.9.6.jar/download

Extract sarissa.js from the jar:
sarissa-0.9.9.6.jar/gr/abiss/js/sarissa/sarissa.js

Replace first part of AJAX.js (till EOF comment) or replace sarissa.js in richfaces souce resources.
richfaces-impl-3.3.3.Final.jar/org/ajax4jsf/javascript/scripts/AJAX.js or richfaces-ui-3.3.3.Final\framework\impl\src\main\javascript\ajaxjsf\

2) For richfaces-impl work in non-compatibility mode in IE9, A4J.AJAX.replacePage method should be fixed in RichFaces sources in AJAX.js or JSFAJAX.js because custom document.open method does not work in IE9 document mode.

Replace (line 2125 in AJAX.js, line 1121 in JFSAJAX.js)
	if(isIE) {  
With
	if(isIE&&!Sarissa._SARISSA_IS_IE9) {

3) You will also need to change or comment the next line in AJAX.js or JSFAJAX.js (richfaces-ui-3.3.3.Final\framework\impl\src\main\javascript\ajaxjsf\)

Replace (line 2119 in AJAX.js, line 1044 in JFSAJAX.js)
	LOG.debug("Hidden JSF state fields: "+idsSpan);
to
	LOG.debug("Hidden JSF state fields: ");//+idsSpan);

Otherwise you get the following error in IE9:

	SCRIPT438: Object doesn't support this property or method
	For this line 2648 in framework pack:
	LOG.debug("Hidden JSF state fields: "+Q);

4) Now you have patched AJAX.js and you can either build a new RichFaces Jar, replace the original AJAX.js in RichFaces Jar with the patched one or just override it in your html.

The easiest way is just include the patched AJAX.js file as the last script-include within HEAD and it will take control over the bundled version of RichFaces.

In your template.jspx or similar:

<html>
	<head>
	<a4j:loadScript src="/js/AJAX_IE9fix.js" />
	...
	</head>
	...

5) Done.

Other ways to fix IE9 compatibility issues has been discussed in tickets RF-10774 as forcing IE9 to use another document mode. Also suggested solutions are to implement a browser sniffer and tell the Sarissa library to use its own XMLSerializer when Internet Explorer 9 is detected and forcing IE9 to run in an emulated mode but neither of those worked for me.

Using the WebLogic Maven Plug-In for Deployment

Using the WebLogic Maven plug-In for deployment is much easier and quicker than going through the WebLogic Server’s AdminServer and Oracle Documentation provides good examples how to do it.

In short, generating WebLogic Maven Plug-In contains following steps:

1. Build the plug-in JAR file using the WebLogic JarBuilder Tool (wljarbuilder) under MW_HOME/wlserver_10.3/server/lib/ with the following command:

java -jar wljarbuilder.jar -profile weblogic-maven-plugin

2. Extract the pom.xml file from weblogic-maven-plugin.jar under the MW_HOME/wlserver_10.3/server/lib directory, and then copy the pom.xml file to MW_HOME/wlserver_10.3/server/lib.

jar xvf MW_HOME/wlserver_10.3/server/lib/weblogic-maven-plugin.jar META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml
 
in Linux:	
cp META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml MW_HOME/wlserver_10.3/server/lib
 
or in Windows:
copy META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml MW_HOME/wlserver_10.3/server/lib

3. Provision the weblogic-maven-plugin.jar in your local Maven repository with the following command.

mvn install:install-file -Dfile=MW_HOME/wlserver_10.3/server/lib/weblogic-maven-plugin.jar -DpomFile=pom.xml

4. Done.

The Maven plug-in can be used e.g. from application’s POM file and be bound to some phase of the Maven life cycle. For example it can be bound to “install” phase and every time you run the “mvn install” command, the deployment plug-in is also called. In my opinion better way to use the plug-in is to add it as a profile so you can call it just when you want with command like “mvn clean install -Pdeploy-wls”.

Maven Project pom.xml File

<profile>
	<id>deploy-wls</id>
	<build>
		<plugins> 
			<plugin> 
				<groupId>com.oracle.weblogic</groupId>
				<artifactId>weblogic-maven-plugin</artifactId> 
				<version>10.3.6.0</version> 
				<configuration> 
					<adminurl>t3://localhost:7001</adminurl>
					<user>weblogic</user> 
					<password>weblogic123</password> 
					<upload>true</upload> 
					<targets>myServer</targets>
					<action>deploy</action> 
					<remote>false</remote> 
					<verbose>true</verbose> 
					<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source> 
					<name>${project.build.finalName}</name> 
				</configuration> 
				<executions> 
					<execution> 
						<phase>install</phase> 
						<goals> 
							<goal>deploy</goal> 
						</goals> 
					</execution> 
				</executions> 
			</plugin> 
		</plugins> 
	</build>
</profile>

The user credentials in the POM file are provided as clear-text but for more security you can use secure configuration authentication mechanism which stores the user name and password in encrypted form in an external file, and then uses it to supply the user credentials with which to connect to the WebLogic Server domain, along with the key that was used to encrypt the file.