Friday, February 24, 2012

Wrap-up: Arquillian Hackfest @ Developer Conference 2012 Brno


Thank all participants for contributing to discussions on Arquillian HackFest!

The 10 people has attended and shared their ideas on selected topics,
and others came to see us on video stream and IRC channel!


The initial idea for this Hackfest has arisen when we were discussing the topics we would like to cover in conference days, just after Arquillian SPI talk from Aslak.


Although we wasn't able to cover all declared topics,
we focused on the ones which were most related to incoming Arquillians,
the notes and white-boards can be find here:

Future: GWT

Future: JavaScript

Future: Performance testing

Future: JSFUnit.NG
( no notes here, it was really short session - after Arquillian SPI talks, it didn't left much more to discuss - thanks Aslak! )


It was pleasure to see so much ideas flowing, let's grab them and equip Ike with even more mighty weapons for fighting with bugs. ;-)

Monday, February 13, 2012

Re-routing JSF resource requests with RichFaces Resource Mapping

Note: The implementation contains issue, thus the samples from this blog needs to be slightly modified, details in this comment. The fix will be available with RichFaces 4.2.1.CR1.

RichFaces resource mapping can save your life when you need to serve a different resource (JS, CSS, image) file than the one originally requested. It works in the stage of determination of the resource request path.

Specifically in all following situations, it may be really handy:
  • providing alternative versions of a resource
  • map several resources to one
  • using external resources
  • moving resources to servers with static content
Before diving deeper into the situations above, let's look at how resources typically works in JSF.

Resource loading in the picture

Component libraries bundle resource dependencies (CSS stylesheets, JavaScript sources, images) in the distribution archives (JARs) and application-specific resources are bundled in WAR - the situation is outlined on the following picture:

Component libraries (JARs) and application web archive (WAR)
and resource dependencies (green)


Let's look at all of mentioned situations one by one:

Providing alternative file

For example, your application requests jquery.js resource, but you don’t want to use default one, you want to provide alternative, maybe patched version to solve some issues. So you provide RichFaces the mapping using following configuration.

Create the file META-INF/richfaces/static-resource-mappings.properties on the classpath of your project and configure one mapping:

jquery.js=jquery-alternative-version.js


All requests for jquery.js will then be served as requests for jquery-alternative-version.js.

jquery.js mapped to jquery-alternate.js

Warning: Resource mapping requires resource servlet for its work - it is automatically registered in Servlets 3.0 environments (JBoss AS 6 and 7, Tomcat 7, GlassFish 3, etc.), but you will need to register that manually in Servlets 2.5 or lower environments - see RichFaces Developer Guide for details of how configure it.

Note: This mapping file needs to be placed in one of following locations: 

{MAVEN_WAR_PROJECT}/src/main/resources/META-INF/richfaces/

{JAR}/META-INF/richfaces/ 

{WAR}/WEB-INF/classes/META-INF/richfaces/

Note: jquery-alternative-version.js needs to be placed in your project on one of following  locations (JSF resource: 

{MAVEN_WAR_PROJECT}/src/main/webapp/resources /

{MAVEN_JAR_PROJECT}/src/main/resources/

{JAR}/META-INF/resources/

{WAR}/resources/
Another example

Or you can similarly map jsf.js resource:

javax.faces\:jsf.js=patched-jsf.js
Note: notice the backslash before the : (it is the escape sequence, required in the properties file)

Map several resources to one

Another requirement comes when you are using several component libraries in one project - oh crap, and they all are based on jQuery and each of them uses another version!

One of solutions here (except using jQuery.noConflict()) is map all requests for different jquery.js versions to one. Let’s define following mapping:

# RichFaces bundled jQuery (following line is not necessary)
jquery.js=jquery.js

# PrimeFaces bundled jQuery
primefaces\:jquery/jquery.js=jquery.js

# Another project bundled jQuery
another\:jquery.js=jquery.js


Okay, now all these libraries use only one version of jQuery - the RichFaces one. ;-)

another:jquery.js mapped to  jquery.js


Using external resources

But resource mapping isn't used only for mapping requests to serve local resources, but external HTTP resources can be served as well.

Let’s show-case this on sample of mapping requests of jQuery library to CDN [1].

jquery.js=http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js

jquery.js mapped to CDN resource


Moving resources to servers with static content

With RichFaces, you can even move all your resources to a server which serves static requests (like Apache Httpd) to lighten your application server. Just map all your resources to HTTP locations.

All application resources are mapped to static server.



That's it, RichFaces Resource Mapping really can save your life! ;-)

Thursday, February 9, 2012

Optimizing Resource Loading with RichFaces 4.2

HTTP connection is an expensive commodity. But if you will look on a traditional rich JSF application, there are many resources for components which need to be loaded, thus many connections need to be established.

The high number of HTTP requests significantly affects application load time and thus overall performance. This applies especially for high-latency network connections like geographically distant places and for mobile networks.

Here you can see profile of loading RichFaces page. You can view sequence of requests made by browser to load all the page dependencies.

JavaScript dependencies

CSS dependencies

When you will look into page source, you will see these resource dependencies defined in the head of the page:

<head> section will all the dependency links


Simple optimization of resource loading comes in form of aggregating several requests into one, thus lightening the load on both the server and the network.

The RichFaces Way

RichFaces offers you the simplest solution available - all RichFaces resources packaged in one file for each resource type - one JavaScript package (packed.js), one CSS package (packed.css).

The only thing you need to do is turn the packaging feature on.

Enabling resource optimization

Open the web.xml file in your project and add following lines:

<context-param>
    <param-name>org.richfaces.resourceOptimization.enabled</param-name>
    <param-value>true</param-value>
</context-param>
Notes: Resource optimization was introduced in RichFaces 3.x as resource loading strategies.

It was reintroduced in 4.1, but for 4.2, its configuration was slightly changed to be more clear and concise. This blog reflects changes committed with RichFaces 4.2.0.CR1. Read more about changes in release blog.

Now, deploy and open your application. When you will open page source, you can see that number of page resources (<script> and <link> elements in the head) was significantly decreased:

<head> section with links to optimized resource dependencies


Also the page load profiles looks much better:

Optimized JavaScript resources

Optimized CSS resources


Packaging and Compression

Resource optimization itself is composed from two features: packaging and compression.

Packaging phase aggregates several resources into one, while compression do JavaScript/CSS compression and obfuscation (powered by YUI compressor).

By default, both packaging and compression are applied on RichFaces resources (in production stage).

However resource optimization is also controlled by the stage of the project. Why?

Development mode

Packaging is not convenient in development project stage.

When you are developing application, some problems may occur in form of JavaScript errors or wrong look because of styling issues. In these cases it’s handy to debug these JavaScript or CSS resources in uncompressed state.

The state of the project is controlled with web.xml switch:

<context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
</context-param>

It will force load uncompressed, but packaged resources - great for debugging the app!

Troubleshooting

When you will have any issues, be sure to look into

Troubleshooting - Resource Optimization article


Summary

As you can see, with RichFaces Resource Optimization, you can achieve decrease of number of resource requests. These resources are also cached by the browsers, so after first page, client get perfect responsiveness.

On the other hand, you are increasing the size of resources which are necessary to be loaded on first request, since all of the RichFaces component resources are bundled in one file.

You need to choose between fast start of the app and responsiveness of the app after first request.

What's the best option for your application, it’s up to you! ;-)

Future Improvements?

We have several ideas how to improve resource loading if it is really critical for your application:

  • several smaller files packaged for certain occasions (core, tables, panels, etc.)
  • provide you maven plugin which will create custom packages just to fit your application needs during the application build!


If you would like to implement any of these features, or have any other ideas for enhancements, be sure to let us know!

Wednesday, February 8, 2012

4 simple steps for RichFaces Push with 4.2


RichFaces Push is a pretty useful component, since it enables you do a server-side push technique (pushing content from a server to a client asynchronously). What makes this component so attractive when there are plenty of other ways to achieve this?

RichFaces is enabling application developers to build on top of push without any additional complexity.

It is enough to use only one interface (which can even be injected using CDI) on the server side. And you need only one component on the client side: <a4j:push>.

In this blog, I’m not going to show all possibilities of how to use the RichFaces Push - instead, I will show you, how to configure this component to work on your favorite container including small sample page and bean. Why?

We have simplified Push drastically along the way from 4.0 to 4.1 and we are continuing in 4.2 to make the process of setting up a project with Push as simple as possible! That’s why I’m sharing our progress with you.

Let’s start...

We will start with SimpleApp maven archetype - it doesn’t have Push configured. It assumes that you have following dependencies installed:
  • Maven 3.0.3+
  • JDK 1.6
  • your favorite editor
  • your favorite servlet container or application server

Creating the project stub

Okay, let’s create the new app based on the SimpleApp archetype:

mvn archetype:generate -DarchetypeGroupId=org.richfaces.archetypes -DarchetypeArtifactId=richfaces-archetype-simpleapp -DgroupId=my.domain -DartifactId=simplepush -Dversion=1.0-SNAPSHOT -Dpackage=my.domain -DarchetypeVersion=4.2.0.CR1


Note: RichFaces Developer Guide may help you when you get stuck with setting up environment:


We have created a stub for our application, now you can try to deploy it on your favorite container and verify basic functionality:

http://localhost:8080/simplepush/

You should see one ajaxified input and when typing, you should see appropriately updated output.

4 simple steps for Push

What are the modifications we will undertake next?
  • install Atmosphere libraries
  • register a servlet (if necessary)
  • add a managed bean with an action triggering a push event
  • add an a4j:push component to the a page

Installing Atmosphere libraries

Atmosphere is the only runtime dependency for RichFaces Push. Atmosphere enables integration with various containers and interoperability between browsers and push techniques (websockets, long-polling).

In order to install Atmosphere in your project, add following lines into your pom.xml, in the section <dependencies>:

<dependency>
    <groupId>org.atmosphere</groupId>
    <artifactId>atmosphere-runtime</artifactId>
</dependency>

Note: version of the dependency is automatically managed by importing the richfaces-bom, that’s why you don’t need to specify <dependency><version> here.

Registering PushServlet

RichFaces Push requires PushServlet registered for web application in order to connect to a container and listen for push requests.

In Servlets 3.0 and higher environments (JBoss AS 6 and 7, Tomcat 7, GlassFish 3, etc.), the servlet will be registered automatically by including RichFaces Core libraries on classpath.

However in Servlets 2.5 and lower, servlet needs to be registered manually in web.xml:

<!-- Push Servlet - listens for user sessions -->
<servlet>
    <servlet-name>Push Servlet</servlet-name>
    <servlet-class>org.richfaces.webapp.PushServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Push Servlet</servlet-name>
    <url-pattern>/__richfaces_push</url-pattern>
</servlet-mapping>

<!-- setups servlet-mapping in RichFaces configuration -->
<context-param>
    <param-name>org.richfaces.push.handlerMapping</param-name>
    <param-value>/__richfaces_push</param-value>
</context-param>

Adding action to the managed bean

Let’s open and edit RichBean.java under src/main/java in package you have defined. Add following methods:

public Date getDate() {
    return new Date();
}

public void push() throws MessageException {
    TopicKey topicKey = new TopicKey("sampleAddress");
    TopicsContext topicsContext = TopicsContext.lookup();
 
    topicsContext.publish(topicKey, "empty message");
 
    System.out.println("push event");
}

Adding component to the page

Open and edit index.xhtml file under src/main/webapp directory.

Replace contents inside of <h:form> with following snippet:

<a4j:commandButton value="Push!" action="#{richBean.push}" />

<a4j:push address="sampleAddress">
    <a4j:ajax event="dataavailable" render="outputDate" />
</a4j:push>

<a4j:outputPanel id="outputDate">
    Date: #{richBean.date}
</a4j:outputPanel>

Accessing sample

When opening http://localhost:8080/simplepush/ again, you should see one button and output with the date.

When clicking on the button, the date should be updated.
But it’s not simple AJAX!

In the background, <a4j:push> opens long-lived session to the server. When you hit button, a server action method publishes the message and RichFaces sends it to all clients which are subscribed to listen on given address topic (determined by the TopicKey). When clients receive that message, an event is fired in order to trigger an AJAX update of the date output.

An advantage over the traditional poll technique is that clients are updated without the necessity of periodically connecting to the server - it off-loads server and provides immediate client updates.

Note: I know, this sample is quite artificial, because real-world applications won’t use a4j:push and updated area on the same page, but the purpose of the blog was mainly show you configuration of the RichFaces Push.

Troubleshooting

If anything didn’t work for you, perhaps you just used the wrong environment and/or you need to configure something additionally, just look at Starting with RichFaces Push on Various Containers article.


Summary

It was necessary to only add Atmosphere libraries to the project generated from SimpleApp archetype, we have made sure that the push servlet is registered and we have setup page and bean with action simply - just enough for showcasing Push component.

Pretty simple, isn’t it?

Who knows what I will cover next time regarding the Push technology in RichFaces? :-)

Hmm, just stay tuned!