Monthly Archives: August 2008

How to install Flex3 builder in RAD7

8 Comments

The IBM Rational Application Developer 7 (RAD 7) IDE, based on Eclipse 3.3 doesn’t work out-of-the-box with Flex Builder 3. This is due to the IBM Java SDK using a different Xerces version then the one Flex Builder needs.

You’ll likely receive the following error:

java.lang.IllegalAccessError:
org.apache.xerces.util.XMLAttributesImpl$Attribute

Here is an easy guide to get you up and running quickly:

  1. Install RAD7
  2. Install Flex Builder 3
  3. At the end of the install, the installer will complain about not being able to automatically setup an Extension Location. Be sure to execute the given instructions manually
  4. Quit RAD7 if running
  5. Edit the eclipse.ini file in c:\Program Files\IBM\SDP70 (directory where you installed RAD7)
  6. Add the following line on a new line at the end of the file:
-Xbootclasspath/a:c:\progra~1\adobe\flexbu~1\sdks\3.0.0\lib\xercesImpl.jar

Restart RAD7 and open the Flex Development perspective to start developing the next-gen Flex app :-)

JSF 1.1 performance fixes

Leave a comment

JSF 1.1_02 is the latest officially released reference implementation of JSF1.1 by Sun. It’s still widely used by companies who have not yet migrated to Java5 (as it is not always easy to migrate all applications to a new target platform).

While looking through the FishEye source code view, I came accross some interesting unreleased performance fixes:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=125

I have been investigating the size of views as they are stuffed in the session for scalability reasons, and have found a couple of issues with the RI code:

1. The biggest problem I found was in StateManagerImpl.The function removeTransientChildrenAndFacets causes the lazy init of the child list, facet map, and client id of every component in the tree! Very, very sloppy.

Fixing this literally halved the size of the view in memory.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=223

StateManager for stateSaving Server has a synchronization lock on (this), blocking all threads. I thought this was fixed a while back.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=222

Currently the checkIdUniqueness forces creation of child and facet arrays onevery component, the suggestion is to switch over togetFacetsAndChildren() which is now optimized within UIComponentBase to avoid unecessary eden creation in memory.

Has anybody already used these JSF 1.1_03 rolling fixes and noticed memory reduction? If so please let us know in the comments!

Fix your Richfaces AJAX (performance) problems

5 Comments

Richfaces supports AJAX functionality in a lot of it components. However a servlet filter is needed for correct functioning of partial page refreshes.

In this post we’ll show you how to add this filter and at the same time optimize Richfaces performance.

The following Richfaces filter is defined in the web.xml:

<filter>
        <filter-name>richfaces</filter-name>
        <display-name>RichFaces Filter</display-name>
        <filter-class>org.ajax4jsf.Filter</filter-class>
        <init-param>
			<param-name>forceparser</param-name>
			<param-value>false</param-value>
		</init-param>
    </filter>

What this filter does, is to ‘tidy’ all HTML HTTP Responses so that they are valid XHTML (thus XML compliant). This is needed as dynamic DOM updates in the browser need correct XML.

If you don’t define this filter, it is possible that you’ll not see your AJAX update being rendered on the screen, although you’ll see the html response coming back in eg. Firebug

Of course, parsing HTML incurs a performance overhead.
This can be minimized by setting the forceparser setting to false. In that case only AJAX responses will be ‘tidied’. In the other case all JSF responses are ‘tidied’. That is because the filter is mapped on the Faces servlet:

<filter-mapping>
        <filter-name>richfaces</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
    </filter-mapping>
Richfaces has a few parsers onboard. The default one is based on Tidy, but it is quite slow. The Neko parser is faster and can be used by setting the following context-param’s:
<context-param>
        <param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
        <param-value>NEKO</param-value>
    </context-param>

    <context-param>
        <param-name>org.ajax4jsf.xmlparser.NEKO</param-name>
        <param-value>.*\..*</param-value>
    </context-param>

Here we say we only use the NEKO filter and it should be applied to all URLs (.)
There is more configuration possible, like using NONE for some pages that don’t need HTML correction to further speedup things if needed.

Example can be found at: http://jboss.com/index.html?module=bb&op=viewtopic&t=116231