Grails JSF 2 plugin with OpenFaces

Now that I have got Icefaces 3 working with the Grails JSF 2 plugin, I am now trying OpenFaces from www.openfaces.org. Since the plugin is compatible with JSF 2.0, I will be using the OpenFaces 3.0 libraries rather than the 2.0 libraries.

To start, you need to create the grails application (grails create-app) and install the JSF 2 plugin (grails install-plugin jsf2). You will also need to install the templates to modify the web.xml file (grails install-templates). Refer to my previous posts on examples of these steps.

For OpenFaces, you will need to copy these libraries into the lib directory:

• openfaces.jar
• cssparser.jar
• jcommon.jar
• jfreechart.jar
• sac.jar

All these files can be found in the openfaces-3.0.zip file, which you can download from the OpenFaces website.

You will also need to make just one change to the web.xml file which is to add the following lines:

<context-param>
<param-name>org.openfaces.validation.clientValidation</param-name>
<param-value>onSubmit</param-value>
</context-param>

That's all that is needed. You can now start creating your OpenFaces app, using xhtml as the extension for the JSF files. You can use the grails create-bean command to create the backing bean for the JSF files.

UPDATE:
There are limitations with the above configuration.  The openfaces.jar library uses Class.forName to resolve some of the classes to unpack (deserialize) the objects.  However, if the classes are defined in the src directory which Grails allows for Dynamic Reloading, then it is NOT available to the jar file class loader (i.e the root classloader). Hence this results in a ClassNotFoundException. This problem occurs when using the run-app (which allows Dynamic Reloading) command.

I tried to unpack the source for the Openfaces components into the src/java directory and include 2 additional jars (portlet api and org.jboss.el).  This then allows the user-defined classes in src to be found since all of the source is dynamic, BUT the faces file parser now does not resolve the namespace for the Openfaces component.  So this is a dead-end.

Alternatively, if you don't need dynamic reloading, you can run the grails app by using run-war command instead.  This will compile all the sources and make it all available to the classloader.  However, there is problem running JSF2 plugin using run-war.  The GrailsResourceResolver.java resolver provided by the JSF2 plugin cannot work in run-war environment as it expects to look for the Grails GSP files like in the development environment instead of the war environment.  If you don't need to use the GSP files, you can make a copy of this file (from jsf2 plugin source directory and put into your project's src/java directory (keeping all the directory paths the same).  Then edit the file and remove all references and code calling the "resourceLoader" member.   Then then allows the run-war to work and you can now run your .xhtml files with the Openfaces components.

Icefaces 3 on Grails with JSF 2 Plugin

Continuing on the previous posts, I have managed to get the new Icefaces 3 libraries working with the Grails JSF 2 Plugin.

To get it working, just follow all the steps in the previous post for Icefaces 2.0.2. For Icefaces 3, download the libraries and replace the all the Icefaces jars on the lib directory with these files from Icefaces 3:
icefaces.jar
icefaces-ace.jar
icefaces-compat.jar
icepush.jar

However, there is one additional change that needs to be made to the web.xml file. Please add the following lines to the web.xml template file:

<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>

If you don't add these lines, when you click on a button (or do a post back), there a Server Error popup will appear and on the console, the system will raise a Java exception as follows:

java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to com.sun.faces.application.view.StateHolderSaver

Please try it and let me know if all the Icefaces 3 features are working with this Grails JSF2 plugin. By the way, this has been tried on Grails 1.3.7.

Icefaces 2.0.2 with Grails

I finally managed to get Icefaces 2.0.2 to run with Grails. The steps are as follows:

1) Create a new grails application:
grails create-app myapp
cd myapp

2) Install the jsf2 plugin:
grails install-plugin jsf2

3) Install the templates to edit the web.xml file:
grails install-templates

4) Copy the following JARs into the lib directory:
icefaces-2.0.2.jar
icefaces-ace-2.0.2.jar
icefaces-compat-2.0.2.jar
icepush.jar

5) Add the following lines into the web.xml template in src/templates/war:
<servlet>
<servlet-name>Resource Servlet</servlet-name>
<servlet-class>com.icesoft.faces.webapp.CompatResourceServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>Resource Servlet</servlet-name>
<url-pattern>/xmlhttp/*</url-pattern>
</servlet-mapping>

<context-param>
<param-name>javax.faces.FACELETS_SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>

<context-param>
<param-name>javax.faces.VALIDATE_EMPTY_FIELDS</param-name>
<param-value>false</param-value>
</context-param>

And that's it. You can now create JSF files with the extension .xhtml in
the grails-app/view directory (following the JSF2 format).

Running Forms 6i remotely without Terminal Services

We still use a lot of Oracle Forms 6i programs in-house and for our customers. One of the issue is that users do not want to install the Forms 6i runtime client on each PC and it also creates deployment issue unless we share out the FMX programs from a central file server. Also, since Forms 6i is only a 32-bit software, it should run only on Windows Server 2003 32-bits Terminal Server, although some users have tried making it work on Windows 7 64-bit. This create another issue on the need to have MS Terminal Service licenses.

However there is another way, which does not even require a MS Terminal Services, and that is to use the following set of packages on Linux: Wine, XRDP and VNC Server.

We started first by installing the XRDP (version 0.5.0) package and VNC-server, running on Centos 5.4, to allow the Remote Desktop Connection program to connect to a window session on the linux server. We have tested this on both Windows XP and Windows 7. Add a new user and test out the remote desktop access to the linux server (the window will ask you for a userid and password). It may start up a window manager (if there are any installed) or just open an xterm.

Next, using the latest version of Wine (1.3.31), we have managed to install the Oracle Forms 6i (Release 2 for XP with Patch 18) runtime and run WITHOUT recompiling the FMX, our existing Forms programs. One problem we faced was that you need to CUSTOM install the Oracle TCP Protocol Adapter which for some reason does not install by default. Also, you may want to install the MS Windows TrueType fonts if it will help. The Forms 6i programs were all installed in the user which we created earlier for the XRDP access.

With that in placed, you can create start-up scripts to auto-run a specific Forms program (via Wine). If you want the XRDP to auto-run your start-up script, you can try modifying the /etc/xrdp/startwm.sh script.

Grails with Richfaces 4

One of my favorite development environment is Grails and I have used plain Grails, Grails with Vaadin, and recently Grails with Icefaces. I have also tried Grails with Primefaces.

I wanted to see if I can use Grails with Richfaces and taking the cue from the Primefaces integration, I started with Grails with the JSF2 plugin. After much trial and errors, I finally have Richfaces 4 running with Grails. In this example, I used Grails version 1.3.7.

Steps:
1. Create the application (grails create-app)
2. Move into the new application directory
3. Install the jsf2 plugin (grails install-plugin jsf2)
4. Install the templates so that we can edit the web.xml file (grails install-templates)
5. Copy the following JAR files into the lib directory:
cssparser-0.9.5.jar, guava-r07.jar, richfaces-components-api-4.0.0.Final.jar,
richfaces-components-ui-4.0.0.Final.jar, richfaces-core-api-4.0.0.Final.jar,
richfaces-core-impl-4.0.0.Final.jar, sac-1.3.jar
The richfaces jars comes from the Richfaces4.0.0.Final download and the rest I googled for them.

That's it. You can create the JSF2 Richfaces pages in the grails-app/views directory with the .xhtml extension (it must be facelet based) and you can create the backing beans using the bean creation script (grails create-bean).

BTW, I couldn't get the Richfaces 3.3.3 version to integrate. If anyone manages to do it, please post the steps.

Oracle OrdAudio and Grails

Recently I have started prototyping some web applications on Grails that uses the Oracle interMedia capabilities. One of the key problems is that you cannot use GORM to define a property which is an Oracle OrdMedia component, such as OrdAudio. I needed a way to stream out the audio data stored in this field in an Oracle database for which I created a Controller in Grails. But how do you retrieve the field object ?

Firstly I used Groovy SQL to get hold of the field by doing the following:

import groovy.sql.Sql

class StreamingController {
def sessionFactory

def index = {
String sqlstr = "select audio_file table where id = ?"
Sql sql = new Sql(sessionFactory.currentSession.connection())
sql.eachRow(sqlstr,[params.id]) { row ->
println row[0]
}
}
}

Invoking the "streaming" url, Grails report that the row[0] is a oracle.sql.STRUCT object. So how do I convert that into an OrdAudio object ?

Turns out that Oracle uses a Factory to build the OrdAudio object from the STRUCT.

sql.eachRow(sqlstr,[params.id]) { row ->
oracle.sql.STRUCT str = row[0]
oracle.sql.CustomDatumFactory factory = oracle.ord.im.OrdAudio.getFactory()
oracle.ord.im.OrdAudio audio = factory.create(str, java.sql.Types.STRUCT)
...
}

So you now have the OrdAudio object for which you can check its properties or extract the audio data out. If the data is stored in the BLOB, then you will use:

InputStream inp = audio.getDataInStream()

If the data is stored in a BFILE, then you will use:

oracle.sql.BFILE bfile = audio.getBFILE()
bfile.open()
InputStream inp = bfile.getBinaryStream()

You can then stream the data into the "response.outputStream" using the write method.

Writing Open Source ESX Network Drivers

Thankfully VMWare has allowed ESXi 3.5 and 4 to be downloaded and used for free. In my office we find that the ESX Hypervisor offers the most usable features (as compared to Oracle VM) but at the expense that the Hypervisor only a limited of number of NICs which are supported out of the box.

Fortunately, due to efforts for websites like http://www.vm-help.com/esx/esx3i/customize_oem_tgz.php and http://sourceforge.net/projects/open-vdrivers, I can now use more common NICs with my whitebox ESX box. But I found that I have a number of Realtek chipset cards (such as the D-Link DFE 538T) lying around and I would like to use them rather than invest in Intel E1000 cards.

So starting with information from these websites, http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/ and http://sourceforge.net/projects/open-vdrivers/forums/forum/915617/topic/3358585?message=7548991, I managed to build a ESX 3.5u4 driver for the RTL 8139 chipset (and its family).

This is my experience of building the driver.

At first I tried using the source for 8139too.c from the kernel 2.4.18 as recommended by KernelCrash. But I hit a road-block as I could not figure out how to fix the reference to skb_copy_and_csum_dev function. In the end I gave up and looking around at various 8139 driver source, I finally found that I could compile the source from 2.4.10 and load it into the ESX system.

There is a simple way to check for unresolved module references without needing the actual PC and card. I created a bootable USB to run ESX and I put a customized oem.tgz driver file into it and booted it up on any PC that will support it. Then I used the command "vmkload_mod new_module.o" to see if the module will load or will it complain. The list of unresolved reference will show up and you can then go back to the source to fix the references.

The next problem was that though the new module will load without problems, it will not been usable by the ESX system. After the driver is loaded, it shows up in the "lspci -p" command but not in "esxcfg-nics -l" listing. And you cannot see it on the command console (yellow band screens). So then I started comparing what unusual lines appear in the source codes for r8168 and r8169 drivers. I found that these source had 2 new lines, in particular,

SET_MODULE_OWNER(dev);
SET_NETDEV_DEV(dev, &pdev->dev);

So I added these lines, near the "alloc_etherdev" line and now there seems to be some
impact when the driver was loaded. Unfortunately, the ESX kernel now crash when it tries to load the 8139too driver. And it has something to do with the copy_from_user routine. Oh and by the way, I also had to rewrite the "interruptible_sleep_on_wait()" to use "schedule_timeout()" and other related lines.

Going back to the drawing board, I looked at the 2.4.18 source again and put in the above 2 lines. In the end, I substituted the "skb_copy_and_csum_dev()" routine with the set of lines from the early version of the driver, which uses dma_addr, etc, and now the driver can compile and there are no more unresolved references other than simple to fix ones.

Now I had a 8139too driver than works on ESXi 3.5 kernel. I have tested it for a while now and it seems to work, though I am not sure if it is efficient.