Wednesday, September 7, 2011

Seam Faces Community Hack Night

This week’s Seam 3 Community hack night is centered around Seam Faces. This is a great chance to mingle with some CDI/JSF developers on IRC, and get your fingerprint into the Seam Faces DNA! Whether you have your own itch you want to scratch, a long-standing bug you want to see resolved, or implement a new feature altogether, we’ve got plenty of low hanging fruit ripe for the picking!

In preparation for the hack-a-thon, I’ve given the Seam Faces JIRA issues a once-over. I’ve collected a number of issues that I feel are ready to be resolved into a JIRA version calles 3.1.0-Tracking. I’d like to highlight a few of the issues here, and perhaps motivate you to come join us at the hack-a-thon to resolve some of them!

SEAMFACES-122: Type safe navigation!

Of all the low-hanging fruit, this one has to be the juiciest! Implement a Navigator utility class to map the @ViewConfig enums to their String @ViewPattern’s for use in JSF navigation. Imagine using your IDE to find all usages of one of your views – type safety FTW!

SEAMFACES-26: Implement global protection against XSRF attacks

Help the community of Seam 3 developers make their apps more secure by implementing a scheme to protect against XSRF attacks! Think hidden form field, view state and a random number generator.

SEAMFACES-28: ObjectConverter and EntityConverter

Let’s resurrect the Entity Converter from Seam 2. The EntityConverter is persistent context aware, and will use the primary key of your JPA/Hibernate entities to handle JSF Conversion.

SEAMFACES-150: Refactor BeanManagerUtils to make use of Solder’s BeanManagerLocator

Are you aware with the Seam Solder API? Want to learn more about how to wield this powerful tool? Here’s a refactoring that will surely get you more comfortable with how to use Solder.

SEAMFACES-6: s:debug

This issue is very well documented in JIRA, and just needs someone to put the pieces together. What a great tool to add to your arsenal once complete!

SEAMFACES-185: Add support for activating beans based on the JSF project stage

Christian Kaltepoth has done a great job with this issue, but we’ve got a tough nut to crack. How to parse the web.xml before the Servlet Context is available? If you got some ideas here, help us bring this one across the finish line.

SEAMFACES-184: Extend an example to demonstrate events propagation features

Familiar with Seam Faces, but don’t feel up to hacking on the core? How about writing an example application, to demonstrate some of Seam Faces’ cool features?

SEAMFACES-152: Create documentation for using Seam Catch in Faces

Another great way to contribute to the project, without writing a single line of code is to contribute docs! Help other Seam 3 devs figure out what you already know!

These are just a few of the issues ready to be solved during the hack night. So drop by on IRC, and give us a hand squashing some issues. At the very least, I’m sure you’ll have fun!

Tuesday, August 16, 2011

Seam Faces 3.0.2.Final released

(cross posted from :

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!


Brian Leathem

Friday, June 17, 2011

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!

Monday, April 18, 2011

Seam Module Spotlight: Seam Faces

This is a blog entry I wrote for 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”:

    public interface Pages {
      static enum Pages1 {

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:


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!

Sunday, March 27, 2011

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:

    public interface Pages {
        static enum Pages1 {

The following annotations are available:

This marker annotation identifies this interface as containing view configuration annotated enums.
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
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.

    @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) {
      "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:

    @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!