RichFaces 4.1.0.M1 Release Announcement

The RichFaces team is proud to announce the first milestone release of RichFaces 4.1. This release includes some significant contributions from community members, adding to and building on top of the efforts of the RichFaces core developer team! You can find this development release on the project’s download page and check out our “getting started” resources.

First Milestone for 4.1

The 4.1.0 Milestone1 release includes several highly anticipated features and improvements in RichFaces 4.

We have new components:

• Editor
• Pick List
• Ordering List
• Notify

In addition, we’ve made some big improvements to the Push component.  It is now more lightweight, decoupled from JMS, and support has been added for Comet - the websockets-like light alternative for long-poliing.  A Push demo has also been added to the RichFaces Showcase, with support for JBoss AS 7 (although not yet visible in the public showcase, the code is available).

In addition, a new sample application Tweetstream has been developed.  This application demonstrates the “mobile platform” directions and capabilities that can be expected from future releases of RichFaces.

New Components

Three of the new components, “Editor”, “Pick List”, and “Ordering List” are components that were available in RichFaces 3, but were not present in the initial RichFaces 4 release.  With this first milestone release for RichFaces 4.1, we have remedied this and provided these missing components.  The 4th new component, “Notify”, is a community contributed component, the first component contributed from Bernard Labno - a RichFaces community enthusiast.  Let’s take a closer look at each of these components:

The Editor component has been rewritten from scratch, and is now based on the CKEditor implementation. It traditionally supports two modes of toolbar button configuration (basic and full) and nicely integrates to rest of the RichFaces AJAX  framework. In the milestone 2 release, it will also get a new Look & Feel to be better aligned with the rest of the component suite.  For further details, see Lukas’ blog post on the rich editor.


The Pick List and Ordering List are two other components that were sorely missed by the community since RichFaces 3, and they have now been re-introduced.  The new Pick List in RichFaces 4 incorporates the functionality of both the List Shuttle and Pick List components from RichFaces 3. The API of this Pick List component has been specifically redesigned to follow the f:selectItems pattern and to allow a quick transition from the h:selectMany component.


Lastly, the Notify component provides interactive feedback from your applications complementary to standard messages.  The look and behaviour of the Notify component was Inspired by Mac OS’s growl to provide your JSF applications with a more rich user experience

The components provided in this first milestone are functionally complete, so you can take them for a spin, and provide us with your feedback about any functionality or key API’s we might have missed (or where we got it right!)

Migration to Git

New features and functionality have not been our sole focus. In preparation for this release we’ve migrated our entire framework to GitHub and broken it up into several modules.  The main goal we had in mind with this migration was to make contributing to the RichFaces framework easier, and help us extend the level of collaboration.  I think we can say we’ve definitely achieved this goal, given the number of community contributions we’ve already seen.

With GitHub, it is now pretty easy to send patches to the project in form of pull requests. Thanks to git-flow it is now trivial process to develop new features in feature branches and, because of Git itself, it is easy to merge them back into the most recent development branch.

Next Milestone

Milestone 2 will be a great sprint for ironing out the details of the new components’ features as well as polish their look&feel.  Most importantly however, we will focus on further stabilization of the framework by fixing bugs both reported by the community and those found by our QE team. A lot of work is also planned for mobile devices support, and as previously mentioned, we are working on initial versions of a Mobile Showcase.

Face to Face Meeting

After Milestone2, the globally distributed RichFaces team will get together with some other JBoss teams in Toronto, Canada,  to discuss the future of the framework itself and it’s integration with other parts of Java EE.  The goal of this meeting is to offer you, the developer, the best development experience possible. Should you be around Toronto in September and would like to join us for an evening beer, you are more than welcome. ;-)

Give it a spin!

Go ahead, and download this first Milestone release of RichFaces 4.1 (or add the dependency to your maven pom file), and give the new components a spin.  Let us know what you think, either where we’ve missed something, or where we got it right, and help shape the component for the upcoming 4.1.0.Final release.

Seam Faces 3.0.2.Final released

(cross posted from :http://community.jboss.org/people/bleathem/blog/2011/06/20/seam-faces-302final-released)

Great news, Seam Faces 3.0.2.Final has been released! It is available for download via the JBoss Nexus repository. Primarily a bug fix release, Seam Faces 3.0.2.Final resolves some compatibility issues with MyFaces, thanks to contributions from Christian Kaltepoth. Additionally, José Freitas has contributed some fixes to issues with the UIInputContainer. A full list of the bugs fixed is available here.

I'm very excited about the community involvement in this release, and with more community members coming forward with features they'd like to see implemented/improved. If you have you're own itches you'd like to scratch, feel free to comment in the forums, file an issue in JIRA, or drop in on IRC. Then it's stratight to the source to fork the project on github! You're pull requests are very much appreciated!

Cheers,
Brian Leathem

Seam Faces @JAXConf/JSF Summit

It's been a while since my last post, as I've gone through a significant career change. I am now working for Red Hat, as a core developer on the RichFaces project. I am also representing Red hat on the JSR-344: JSF 2.2 Expert Group, and will continue in my role as Seam Faces module lead.

As such, I'll be presenting at JAXConf/JSF Summit on the topic of Seam Faces. I really like this presentation, as I not only go into the features provided by Seam Faces, but I show how some of those features are implemented taking advantage of the platform extension points built into CDI and JSF. I'll also introduce how we are using Arquillian, Shrinkwrap, and JSFUnit to test Seam Faces, and how you can use the same toolset to test your own applications with independent and isolated in-container tests.

So if you are at JAXConf/JSF Summit, be sure to come see my talk, or grab me at any time to share your thoughts on where you would like to see Seam Faces going in the future - I'll be more than happy to discuss solutions, and point you to the git repository!

Seam Module Spotlight: Seam Faces

This is a blog entry I wrote for in.relation.to. I'm including it here to keep a personal record of the post.

---

In this entry for the Seam Module Spotlight series, we will take a close look at the “view configuration” feature of Seam Faces.

Seam Faces aims to provide JSF developers with a truly worthy framework for web development by ironing out some of JSF’s pain points, integrating tightly with CDI, and offering out of the box integration with the other Seam Modules and third party libraries. Part of achieving this goal involves providing a means to centrally configure each of these seemingly disparate concerns, without having to create any JSF Phase listeners, nor maintain a bunch XML files.

Adhering to the CDI core tenet of type safety, Seam Faces offers a type-safe mechanism to configure the behaviour of your JSF views. So far these configurable behaviors include:

1. Restricting view access by integrating with Seam Security
2. Configuring URL rewriting by integrating with PrettyFaces (or any other pluggable URL rewriting framework)
3. Configuring Transactions via Seam Persistence
4. And a personal favorite: setting “?faces-redirect=true” when navigating to a view.

Note: the above integrations are optional, you must include the relevant jars in the application for their respective configurations to have any effect

Lets take a closer look at the View configuration from the Seam Faces example “faces-viewconfig”:

@ViewConfig
public interface Pages {

  static enum Pages1 {

      @ViewPattern("/admin.xhtml")
      @Admin
      ADMIN,

      @ViewPattern("/item.xhtml")
      @UrlMapping(pattern="/item/#{id}/")
      @Owner
      ITEM,

      @ViewPattern("/*")
      @FacesRedirect
      @AccessDeniedView("/list.xhtml")
      @LoginView("/login.xhtml")
      ALL;

  }
}

At first glance, the structure of the above configuration might appear odd. The @ViewConfig annotation is on the interface, and the interface is nothing more than a container for a static enum. This arrangement is unfortunately required by the current CDI specification for the view configuration annotations to be scanned, and will hopefully be corrected in future iterations of the CDI spec.

The properties of the enum are annotated with a @ViewPattern annotation, specifying to which views the adjacent annotations apply. ViewPatterns support wildcards, and matches are made to a particular view weighted by the specificity of the match; therefore, if two annotations paired with different @ViewPatterns conflict for a given view, the annotation paired with the more specific @ViewPattern takes precedence.

Seam Security via the @ViewConfig
Now let’s look at the Seam Security annotations @Admin and @Owner. These annotations are user-provided, meaning they were built solely for this example, and are qualified with the Seam Security qualifier: @SecurityBindingType. When a view is requested that matches a pattern in the @ViewConfig annotated with such an annotation, Seam Faces invokes Seam Security to determine if access should be granted. Authorization is evaluated with the following class:

public class SecurityRules {
public @Secures @Owner boolean ownerChecker(Identity identity, @Current Item item) {
if (item == null || identity.getUser() == null) {
return false;
} else {
return item.getOwner().equals(identity.getUser().getId());
}
}

public @Secures @Admin boolean adminChecker(Identity identity) {
if (identity.getUser() == null) {
return false;
} else {
return "admin".equals(identity.getUser().getId());
}
}
}

In this way, views annotated with the @Owner annotation are secured by the @Secures method annotated with the same @Owner annotation. Coupled with parameter injection, this is truly a declarative syntax for securing view access.

Furthermore, the @Admin annotation is defined with an additional qualifier:

@RestrictAtPhase(PhaseIdType.RESTORE_VIEW)

This annotation causes the security restriction to be applied at the “Restore View” phase, rather than the default phases: “Invoke Application” and “Render Response”. These default phases were chosen in order for application data to be present and allow access restrictions to be contextual. The default phases also mean that the security restrictions are evaluated twice per lifecycle, as the view often changes at the end of the “Invoke Application” phase.

URL rewriting via the @ViewConfig
The view config also let’s us configure URL rewriting for a view using the @UrlMapping annotation. In the above @ViewConfig, the URL /item.jsf?item =1 would get mapped into /item/1/, courtesy of PrettyFaces and the annotation: @UrlMapping(“/item/#{id}”). In this mapping, “#{id}” tells the rewriting-engine to treat the last portion of the URL as the value of the the query-parameter named “id”. By integrating the configuration of rewriting URLs alongside the rest of the view configuration, Seam Faces attempts to make this powerful technology more accessible, and a core part of JSF application development.

Setting faces-redirect=true
A seemingly simple annotation, @FacesRedirect is a surprisingly useful one. When this annotation is present with a @ViewPattern, any navigation to a matching view is intercepted, and the faces-redirect attribute is activated. In the provided example the @FacesRedirect annotation is applied once to the pattern “/*”, which applies the configuration to all views. One could optionally override this catch all setting on a more specific pattern, or on an individual view, with the annotation @FacesRedirect(false). This annotation has a special place close to my heart - no more “?faces-redirect=true” peppered throughout any more applications!

Seam Persistence via the @ViewConfig
Last, but not least, there is the SeamManagedTransaction annotation that can be applied in the @ViewConfig. This allows transactional behaviour to be defined on a per view basis. Exploring the possibilities here will be the subject matter for a subsequent post.

The future for the @ViewConfig component of Seam Faces is bright, with many more capabilities to be added. In addition, the @ViewConfig presented here is merely a front-end to an internal store of the view configuration data. This opens up the possibility of providing alternate means of populating the view config data store, writing extensions to perform custom operations on view config data for your individual application, and more. One solution being explored is to introduce child tags to the f:metadata tag, which will allow view related concerns to be defined from within the view itself. Additionally, configuration sources like xml and database persistence could be incorporated to provide developers with more options.

Seam Faces provides a centralised, type safe way of configuring the behaviour of your JSF views. Try the ViewConfig out and be sure to send in your feedback. This is still early days for the feature, and all feedback is very much appreciated!

RichFaces Plugin for Seam Forge

If you haven't yet heard about it, Seam Forge is a fantastic new tool from JBoss for rapid application development of standards based applications. Forge allows a developer to quickly set up the scaffolding for an application, and quickly get to the matter of solving domain problems.

What makes Forge particularly interesting, from my perspective, is the way it was built with plugins in mind as a defining way in which the platform is meant to be extended. To take this new tool for a spin, I created a Forge plugin for RichFaces - the killer component kit for JSF 2.

For instructions on installing Forge, refer to the Forge Documentation. The following guide assumes you have Forge installed and functional.

** The instructions in this blog are for the 0.1.0 version of the RichFaces plugin for Seam Forge. See the project's README.txt for update usage instructions. **

First, lets install the RichFaces plugin for forge (installing from git!):

$ forge git-plugin git://github.com/bleathem/richfaces-forge-plugin.git

Forge makes it easy to create a new project:

$ new-project --named richfacesApp --topLevelPackage ca.bleathem.richfaces.test --projectFolder richfacesApp

Next, make the project a Java EE wep app, by installing the "servlet facet":

$ project install-facet forge.spec.servlet

Now, we can run the "richfaces" command, with no arguments to see the options available:

$ richfaces
Use the install commands to install:
  install-base: maven dependencies, and web.xml configuration
  install-example-facelet: a sample RichFaces enabled facelet file with backing bean
  install: both base and example-facelet

Running "richfaces install" duplicates the behaviour of the existing RichFaces maven archetype. If you have an existing project, and you just want to use forge to add the RichFaces dependencies and setup the web.xml, run "richfaces isntall-base". For our vanilla application, we'll run the full install, and see a simple facelet page with an input component "ajaxified" with RichFaces.

$ richfaces install
***SUCCESS*** RichFaces BOM dependency has been installed.
***SUCCESS*** org.richfaces.ui:richfaces-components-ui:4.0.0.Final dependency has been installed.
***SUCCESS*** org.richfaces.core:richfaces-core-impl:4.0.0.Final dependency has been installed.
***SUCCESS*** javax.servlet:servlet-api dependency has been installed.
***SUCCESS*** javax.servlet.jsp:jsp-api dependency has been installed.
***SUCCESS*** javax.servlet:jstl dependency has been installed.
***SUCCESS*** net.sf.ehcache:ehcache dependency has been installed.
***SUCCESS*** javax.faces.PROJECT_STAGE context-param has been installed.
***SUCCESS*** javax.faces.SKIP_COMMENTS context-param has been installed.
***SUCCESS*** Faces Servlet mapping has been installed.
Wrote /home/bleathem/NetBeansProjects/richfaces/richfacesApp/src/main/webapp/WEB-INF/web.xml
Wrote /home/bleathem/NetBeansProjects/richfaces/richfacesApp/src/main/webapp/templates/template.xhtml
***SUCCESS*** template.xhtml file has been installed.
Wrote /home/bleathem/NetBeansProjects/richfaces/richfacesApp/src/main/webapp/index.xhtml
***SUCCESS*** index.xhtml file has been installed.
Wrote /home/bleathem/NetBeansProjects/richfaces/richfacesApp/src/main/java/ca/bleathem/richfaces/test/RichBean.java
***SUCCESS*** RichBean class has been installed.

This new RichFaces enabled maven project is ready to be opened up in your favorite IDE (I used Netbeans) and run in your preferred run-time container (I used Glassfish 3.1).

This is early days for this plugin. I achieved my initial goal of being functionally equivalent to the maven archetype, but there is plenty of room for improvement. Some of my ideas are:

• Make the sample facelet page more attractive, and showcase more of RichFaces capabilities
• Test and support the generated application in more containers - including Servlet 2.5
• Scan and convert vanilla facelet tags (or tags from other frameworks) converting them to RichFaces components. I'm thinking specifically dataTables, but I'm sure this would work well for other components.
  

Fork away, lets show the power of Seam Forge with the RichFaces plugin!

View Configuration with Seam 3 Faces - the Introduction

In Seam Faces we've provided JSF developers with a mechanism to centrally configure various aspects of their JSF views. Concerns like transaction control and view security are currently supported, and support for URL rewriting, XSRF attack prevention, and JSF navigation is in the planning stage.

The end-goal is to support view configuration via multiple sources (including some support for <f:metadata> child tags). For now we provide type-safe configuration using annotations on enums. The benefit of type-safety for page configuration is a tremendous benefit, and will become evident in the following code examples.

In this post I will cover the @ViewConfig security annotations supported in the Seam 3.0 release. This view configuration feature is still considered "beta" and the @ViewConfig API is subject to change in upcoming releases - based on the feedback we get from you, our community of Seam developers!

(Note: Seam Faces delegates authorization checks to Seam Security, which must be included in your project for the security annotations to have any effect)

Consider this @ViewConfig interface:

@ViewConfig
public interface Pages {
 
    static enum Pages1 {
 
        @ViewPattern("/*")
        @LoginView("/login.xhtml")
        @AccessDeniedView("/item/list.xhtml")
        ALL,
 
        @ViewPattern("/admin/*")
        @Admin(restrictAtPhase=RESTORE_VIEW)
        ADMIN,
         
        @ViewPattern("/item.xhtml")
        @Owner
        ITEM;
    }
}

The following annotations are available:

@ViewConfig

This marker annotation identifies this interface as containing view configuration annotated enums.

@ViewPattern

This contains the view pattern to which these annotations apply. Notice the use of wildcards in the view

@LoginView, @AccessDeniedView

The viewIds to redirect to for for authentication, and authorization failure

@Admin, @Owner

These "security" annotations are qualified with @SecureBindingType from Seam Security. The authorization methods themselves are each annotated with both the @Secures annotation and the corresponding "security" annotation

@RestrictAtPhase

Specify the phases at which the security restrictions will be applied. Default phases are the Invoke Application and Render Response phases

The secret sauce is in the annotations qualified with the @SecureBindingType qualifier.

@SecurityBindingType
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE})
public @interface Owner {
}

These annotations are mapped to methods that check for appropriate authorization, functionality provided by the Seam Security module. The authorization methods themselves are annotated with @Secure and the corresponding @SecureBindingType qualified annotation, as in the class below:

public class SecurityRules {
 
    private transient final Logger logger = Logger.getLogger(SecurityRules.class.getName());
 
    public @Secures @Owner boolean ownerCheck(Identity identity) {
        if (identity == null || identity.getUser() == null) {
            logger.info("Identity/User is null");
            return false;
        } else {
            String id = identity.getUser().getId();
            logger.infof("Username is: %s", id);
            return "demo".equals(id);
        }
    }
 
    public @Secures @Admin boolean adminCheck() {
        return false; // No one is an admin!
    }
}

So how do these pieces fit together? Consider a request for the view /list.xhtml. This would match the view pattern, "/*" and access would be granted, as no SecureBindingType qualified annotation is present. On the other hand, a request to the view /item.xhtml is matched by the more specific pattern "/item.xhtml", and the request would be intercepted. Authorization would be checked according to the method annotated by @Secures, and @Owner, and the user redirected to the login view /login.xhtml. If the user was already logged in, and authorization still failed, the user would be instead redirected to the access denied view. If these views are not defined by their respective annotations, a 401 response is returned.

The enforcement of security restrictions is highly tuned to the JSF life-cycle. By default, authorization is checked before the Invoke Application and Render Response phases (because the view requested may change between these phases). However, by including a "restrictAtPhase" method on SecureBindingType qualified annotation, the phases at which that restriction is applied can be fine tuned. Additionally, the @RestrictAtPhase annotation can be applied to an enum value to change the default phase for all SecureBindingType qualified annotations on enums values that match that pattern. In the example above, the @Admin restriction would be checked at the RestoreView phase, and the @Admin annotation is defined as follows:

@SecurityBindingType
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE})
public @interface Admin {
    public PhaseIdType[] restrictAtPhase();
}

While there are a lot of controls to fine tune your security requirements, the defaults are sensible (we hope!) and your security configuration can be quite straight forward. Of course one still has to configure Seam Security to perform the authentication - see the Seam 3 Security module page for further details.

In an upcoming blog series, I'll examine use cases, and propose how we can build more annotations into the view configuration to further centralize application configuration. The @ViewConfig API will also be further refined, based on community feedback. Feel free to leave comments here, or in one of the many communication avenues of the Seam framework with any ideas you have on how this feature can be refined. And of course, we're always looking for more developers to jump in and contribute!

Updating Weld in Glassfish 3.1

Like any piece of software, Weld, the reference implementation for JSR-299, is continually improving as bugs are discovered, and performance is optimized.  However, since Weld is tightly coupled with your application server of choice, using the latest weld is slightly more complicated than just bundling a weld release with your web application.  This post outlines the relatively painless process of updating the Weld implementation of Glassfish 3.1 to use the latest SNAPSHOT, or any later release for that matter.

A quick search of the Glassfish folder structure identifies the Weld implementation:

$ find /opt/sun/glassfish/ -iname '*weld*'
/opt/sun/glassfish/glassfish/modules/weld-integration-fragment.jar
/opt/sun/glassfish/glassfish/modules/weld-integration.jar
/opt/sun/glassfish/glassfish/modules/weld-osgi-bundle.jar

The weld-osgi-bundle.jar is the file we have to replace. But how does one go about creating such an OSGI bundle? I for one am not an OSGI expert, and I'm sure I'm not alone :P

---

Update: The Weld OSGI bundle is now published to the maven repository.  Instead of building it yourself, you can download it via:

https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/weld/weld-osgi-bundle/1.1.0-SNAPSHOT/

---

Not to worry, the weld guys have this in hand. The OSGI bundle is built as an artifact during the weld build. To begin, proceed to the Weld core github page,  and checkout the project:

git clone https://github.com/weld/core.git
cd core

I had a bit of trouble building the entire project, due to the requirement of some deprecated artifacts. So just build the impl module in core:

cd impl
mvn clean install

Next, build the OSGI bundle:

cd ../bundles/osgi/
mvn clean install

Now take that newly created Weld OSGI bundle, and use it to replace the Glassfish weld-osgi-bundle.jar file we located earlier.

cp target/weld-osgi-bundle-1.1.0-SNAPSHOT.jar /opt/sun/glassfish/glassfish/modules/weld-osgi-bundle.jar

Restart Glassfish, and you should see a message in the log file along the lines of:

INFO: Updated bundle 75 from /opt/sun/glassfish-3.1-b41/glassfish/modules/weld-osgi-bundle.jar

And there you have it, Glassfish 3.1 running with the latest Weld.  Thanks to Stuart Douglas who guided me through the process!

Note: this will not work to get Weld 1.1+ to run on Glassfish 3.0.1, as the interface between Glassfish and Weld changed considerably with Weld 1.1/Glassfish 3.1. However that interface is for the most part stable, so we can use newer releases of Weld on Glassfish 3.1.