Java EE - Experiences of a developer

RichFaces 4.2.0.CR1 Release Announcement

2012-02-08T08:23:00.000-08:00

I’m excited to announce the availability of RichFaces 4.2.0.CR1, our release candidate for RichFaces 4.2.0. Hot on the heels of the RichFaces 4.1 release, Richfaces 4.2 delivers some "missing" components migrated from RichFaces 3, and offers usability and API improvements for those looking to take advantage of our resource loading optimizations, and push API. Not to forget a significant number of bug fixes, and overall usability improvements.

To try out this release, you can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.2.0.CR1. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Let’s begin our look at the RichFaces 4.2.0.CR1 release with a look at the new components: rich:contextMenu and rich:hotKey.

New Component - rich:contextMenu
The rich:contextMenu component provides hierarchical context menu system similar to those found in many desktop applications, and was widely sought after by our community with a significant number of votes in our issue tracker. I’d like to thank our loyal and persistent community for identifying the gaps in our RichFaces 3 -> Richfaces 4 migration story, and assure you that we will continue to work diligently to ease the migration process.

The rich:contextMenu itself is built on top of the existing rich:dropDownMenu implementation, making it a natural fit into the RichFaces 4 component set. The rich:contextMenu has 3 modes of operation client, ajax, and server, and integrates with the row/node selection capabilities of the rich:extendedDataTable and rich:tree components. The RichFaces showcase includes examples of each of these features.

The RichFaces 3 feature of "macrosubstituion" (client side string replacement) for the contextMenu has been so far omitted from the feature, but is being racked via jira (RF-11842). Be sure to vote for this issue if you feel it’s important to include in a future Richfaces 4 release. Likewise, be sure to file any jira issues should you have additional use-cases we’ve overlooked.

New Component - rich:hotKey
The rich:hotKey component is another ported Richfaces 3 component we are making available with our 4.2.0.CR1 release. The rich:hotKey component allows one to register a "hot key" on the page (or on a particular component) to execute some logic when the registered key-combination is pressed. This is functionality is often sought after in "heads down" data entry style applications, but is also valuable in any use case where one wants to enable "mouse free" operations. Many thanks to Ilya Shaikovsky for the pull request porting this feature to Richfaces 4.

Improvements - a4j:push
The a4j:push component has seen some attention, improving it’s usability with this release. First and foremost is our decision to turn off JMS integration by default - as of RichFaces 4.2.0, JMS integration must be explicitly turned on (RF-11892). This breaking change was introduced to ease the on-boarding of new users with push technology, as the component now works in both Servlet and EE containers out-of-the-box. Those who want to leverage the benefit of JMS integration will now have to explicitly enable it with the contextParam in your web.xml:

<context-param>
    <param-name>org.richfaces.push.jms.enabled</param-name>
    <param-value>true</param-value>
</context-param>

Another usability improvement has been the introduction of on-demand topic creation (RF-11483). The significance of this change is that you no longer need to implement a ServletContextListener, initializing your topics at application startup time. Instead, topics will be created on first access. Similarly, the push component itself will be initialized on first use.

However, when using push outside of the FacesContext threads (JMS-end points, timers, etc.) you will need to continue initializing push on startup, so that the push feature has a reference to the right contexts when called from those external threads. To do so, enable the context-param org.richfaces.push.initializeOnStartup in your web.xml.

Lukas Fryc has a great blog post giving an introduction to using the 4.2 a4j:push technology. We'll have the Developer Guide updated with a complete description of using this feature in time for the 4.2.0.Final release.

Resource Loading
With our 4.1 release, we introduced our resource loading optimisation feature. Unfortunately, we conflated the ideas of resource mapping, with resource minification/packaging. There are valid use cases to enable resource mapping, while requiring neither minification, nor packaging, such as providing your own patched version of jsf.js, or even replacing the packaged version of jQuery with your own.

To better reflect these use cases, we re-worked the context-params that enable the feature, renaming them to clarify their purpose, and introduced a resource mapping file (independent of the mapping file used with resource packaging - RF-11909). The 4.1 context-params map into the new 4.2 context-params as follows:

RichFaces 4.1 context-param		RichFaces 4.2 context-param
org.richfaces.resourceMapping.enabled	→	org.richfaces.resourceOptimization.enabled
org.richfaces.resourceMapping.compressedStages	→	org.richfaces.resourceOptimization.compressionStages
org.richfaces.resourceMapping.packedStages	→	org.richfaces.resourceOptimization.packagingStages

Note: The 4.1 context-params will work in 4.2, they will be removed in a subsequent release

The significance of this, it that application developers can now create a simple mapping file, overriding the individual entries of the default mapping file without having to re-execute the whole packaging/minification process.

Look forward to some forthcoming blog posts detailing how to make use of the Resource Loading optimisations in RichFaces. We'll also have the docs updated in time for the 4.2.0.Final release.

Skinning Improvement - Rounded Corners
A pull request from a community member (Adrian Gonzalez) enables round corner support in the RichFaces skins (RF-11848). This feature takes advantage of the border-radius CSS 3 property, and so will only work with compatible browsers - with a safe fall back to square corners in browsers that don’t support this CSS property. The screenshot below demonstrates what the RichFaces showcase looks like, with round corner support enabled.

To enable round-corner support for your skin set the panelBorderRadius property of your skin to the desired border-radius value.

Note: panelBorderRadius is not used in any of the out-of-the box 4.2 themes

Miscellaneous fixes
A number of other notable improvements include:

jQuery upgraded to v1.7.1 (RF-11838)

Fixes the "event.layerX and event.layerY" deprecation warning in Google Chrome

RichFaces available via maven central (RFPL-1800)

No longer is it required to define the JBoss nexus repository in your settings.xml to consume richfaces maven artifacts

Mobile tweaks

improvements to the mobile getting started guide
component specific usability improvements

Spring Webflow compatibility (RF-11806)
a4j:actionListener example in the showcase

omitted in our initial release of the showcase, an example of a4j:actionListener usage has been added to the 4.2 showcase

Build improvements

The dependency management across all the projects’ poms has been cleaned up and centralized

Moving forward
With RichFaces 4.2.0.CR1 in the hands of our community, we look forward to hearing your feedback on this release, particularly if we missed any regressions. Should 4.2.0.CR1 be well accepted by our community members, we will release RichFaces 4.2.0.Final as a simple respin of CR1. In the mean time we will work on getting our 4.2 docs finalized, including an effort to fill in the missing attribute descriptions of our tag library documentation (VDL doc).

Looking beyond 4.2, we will consolidate many of the great ideas brought forward in our "4.3 and beyond" planning discussion into a project roadmap, and start some prototyping to spearhead our new initiatives.

RichFaces 4.1.0.Final Release Announcement

2011-12-13T10:22:00.000-08:00

I’m thrilled to announce the release of RichFaces 4.1.0.Final. It’s been a long road from 4.0 to 4.1, with a significant train of milestone releases along the way. The journey was worth it though, with a significant 4.1 release building on top of the successful 4.0.0.Final release, providing: additional components migrated from the RichFaces 3 component set, altogether new components, and significant enhancements to the framework feature set.

To try out this release you can download the distribution directly, or for maven users increment the RichFaces version in your pom.xml to 4.1.0.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Let’s dive in, and look at some of the details of what’s new in RichFaces 4.1!

New Components

We’ve delivered a number of new components in this release:

Not only have we migrated forward more RichFaces 3.x components, but we’re also providing an altogether new component - the notify component - put together by Bernard Labno, a RichFaces community member.

Mobile Compatible Components
We’ve leveraged HTML 5 and CSS 3 to create a set of resources that make the existing RichFaces components mobile compatible. Check out the results yourself in our mobile showcase with your webkit-based mobile phone, (or checkout the mobile showcase directly with your desktop browser).

We’ve put together a comprehensive guide detailing how you can take advantage of this approach with your own applications, and deliver a modern mobile application today - leveraging your existing skillset and investments in both JSF and Richfaces.

Not all the components make sense in a mobile environment, and not all mobile browsers are equally capable. Be sure to also take a look at our mobile design document, outlining the choices and compromises we had to make.

Showcase
Along with this new mobile face, the Richfaces showcase has undergone a number of additional significant changes.

We’ve deployed the showcase to OpenShift, Red Hat’s PasS offering. The OpenShift Java EE 6 support provides a great platform to take your application all the way from development with Express (free!) to production with Flex (highly scalable!). For the RichFaces project, this gives us the chance to showcase our components in a Java EE environment, where our framework really shines!

We’ve also included samples for the new components listed above, as well as a rich:push component sample, keeping it straightforward to incorporate advanced RichFaces components in your application. Lastly, a number of bug fixes and simple improvements throughout the showcase have overall improved the user experience of the showcase itself.

Individual component improvements
I’d like to single out a few component enhancements from this release:

rich:push: Push has been de-coupled from JMS, allowing RichFaces users to take advantage of push technology in non-JMS (ie. servlet) environments.; A CDI API has been provided for firing push events - aligning the push component with the standardized Java EE programming model
rich:fileUpload: Some events that were missing from the 4.0 release have been added, including the onclear event
drag and drop: A bug with dynamically rendering of drag sources and drop targets has been resolved, improving drag/drop functionality in components like the rich:tree
rich:extendedDataTable: For those creating RichFaces skins, you’ll be happy to hear we replaced the cellpadding and cellspacing attributes of the extended datatable with CSS equivalents, allowing skins to override the values

For a complete listing of issues resolved, refer to the release notes of each of the milestone releases: 4.1.0.M1, 4.1.0.M2, 4.1.0.M3, 4.1.0.M4, 4.1.0.CR1, 4.1.0.CR2, 4.1.0.Final

Resource packaging
Another great feature with this release is the Resource packaging and minification. An absolute necessity when developing for mobile applications, this feature can provide performance improvements to your desktop applications as well by dramatically reducing the number of javascript and CSS files the browser client has to download. Read the docs to see how you can activate this for your applications.

For those looking for the RichFaces 3 LOAD_NONE capability, you can use this resource minification configuration to achieve the same results.

Source hosted on github
A significant achievement early in the 4.1 development process was the migration of our source code version control system from svn to git, specifically hosted on github.com. We noticed significant advantages to using git, both within our team, and in our collaboration with community members. Git’s ability to enable a sophisticated workflow, and encourage community contribution in the form of pull requests has made “bit management” a pleasurable task.

Other noteworthy items
It’ worth pointing out that RichFaces 4.1 ships with an updated jQuery release (v. 1.6.4). Keeping the jQuery release version up-to-date facilitates RichFaces inter-operability with other jQuery plugins.

RichFaces 4.1 works with a number of modern browsers, however it currently requires Internet explorer 9 to be run in compatibility mode, due to an upstream mojarra issue.

Documentation
Lastly, I’d like to remind everyone of the availability of the RichFaces documentation:

These docs are a great resource detailing how to make use of the RichFaces framework in your application. They are however an ongoing effort, with some specific areas that need improvement. Specifically we need to flesh out the descriptions of the VDL tag library doc (note: the attribute listing is complete), and we need to vet the migration guide. This is a great way to get involved, should you want to contribute to the project!

Looking Forward
In a recent blog post, I laid out a strategy for the future of the RichFaces project, and extended an invitation to all who would like to have a say in future directions in our development forum. While RichFaces 4.1 undoubtedly provides some great fixes and features, we are excited about the future direction of the project, and what we can offer moving forward!

State of the RichFaces

2011-12-09T08:45:00.001-08:00

With a RichFaces 4.1.0.Final release on the horizon, now is a good time to talk about the future of the project. Let me start by announcing that I will be taking over from Jay Balunas as lead of the RichFaces project. Jay has been a long-time shepherd of RichFaces from within JBoss, and has had a direct hand in making the project such a great success. Jay has been a terrific mentor and while he is stepping down as the project lead, he will continue to stay involved, sharing his insight and experience with the Richfaces team. He will just no longer get the final word ;)

Moving forward, I would like to see the project continue to focus on the key strengths that have made RichFaces such a great project to be involved with: innovation, open standards, community, and quality.

Innovation

RichFaces has long been the place to come for JSF innovation. Never content to simply provide a JSF component set, the RichFaces project (together with other JBoss projects) has always aimed to provide developers with a complete JSF framework for developing applications. Some of these innovations include:

Pioneering JSF ajax support
Client side validation
Ajax Push component - leveraging websockets where available
The CDK (Component Development Kit) - in RF 4 the CDK builds on top of the JSF 2 composite components feature
Support for mobile browsers in our base component set
Resource packaging and minification
Advanced queuing
Sophisticated tooling support (together with JBoss tools)

Open Standards

Richfaces has played a significant role in improving the JSF specification with contributions to JSF 2.0, particularly in the area of ajax integration. RichFaces also aims to improve the standards story by integrating JSF with other Java EE standards in some of the same innovations mentioned above:

Client side validation brings Bean Validation into the client environment
The push component couples JMS messaging with our JSF component set
The push component also leverages CDI, providing building on the standardized Java EE programming model

Community
RichFaces is also very much a community oriented project. Both our development and planning efforts are done out in the open, with an open door to anyone who wants to help out. Some of the ways we actively work to facilitate community interaction include:

A user forum with an incredible amount of traffic
Weekly team meetings held openly in IRC
A developer forum - where new ideas for the framework are worked out
Active use of social media (twitter, Google+)
Github hosting - facilitating community contributions

Quality
RichFaces is a very well tested project, with a dedicated QE team that continually writes new tests for the framework, and ensures that existing tests continue to pass in their automated runs. Look forward to some upcoming blog posts, where we will expand on our testing strategy, and speak to the industry leading role JBoss is taking with projects like Arquillian, JSFUnit, and how we build on that with RichFaces. This all comes together in a robust, enterprise-ready platform on which you can develop and deploy your applications.

Moving Forward
Moving forward we plan to keep up this pace of innovation with our 4.Next efforts. The existing component set is crucial to the project, and will continue to see new improvements and additions - but we need a new vehicle to deliver new components faster and more effectively. We would like to be able to better leverage the mountain of work done in other OSS projects in the javascript component space, and facilitate contributions from prospective contributors looking to implement their own “critical components”. To this end, we are proposing the addition of another component set in the RichFaces project.

This new component sub-project will leverage existing javascript code where possible, either directly, or by composing them into new components. Where use cases require, we will continue to develop new components, contributing back to upstream javascript projects wherever possible. This idea is currently at a proposal stage, with a proof-of-principle demonstrated my recent CDK blog series. Join us in the developer forums, as we work out the details of how to build this next-generation component set.

Thanks to all of you for your interest and contributions to the project, feel free to ping me in the forums, IRC (in #richfaces), twitter or anywhere for that matter should you want to discuss how you can contribute to the project, and help shape it into what you need it to be!

RichFaces 4.1.0.CR2 Release Announcement

2011-12-06T09:57:00.001-08:00

We are announcing the release of RichFaces 4.1.0.CR2, a second release candidate for RichFaces 4.1. We had a couple of regressions that were introduced in the 4.1.0.CR1 release that we’ve addressed in the with this CR2 release. The expectation is that CR2 will be re-tagged and released as 4.1.0.Final, provided no blocking issues are found. Our QE team has done a great job running their test suite against this release, but I encourage as many community members as possible to download the CR2 release, and make sure it’s “up to snuff”!

To try out this release, you can download the distribution directly, or for maven users increment the RichFaces version in your pom.xml to 4.1.0.CR2. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Noteworthy changes
In addition to addressing the above regressions, our CR2 release has addressed a couple other noteworthy issues.

showcase tweaks: improving the user experience on both desktop and mobile
archetype improvements: including the addition of an option for creating a mobile project
skins: warning messages had an unreadable color on a white background - (warningColor) [RF-11673]
rich:inplaceInput: a fix for client side validation [RF-11633]
rich:dataTable: a fix for a regression effecting component decoding [RF-11675]
rich:calendar: a fix for a regression selecting dates in the popup [RF-11677]
rich:pickList: a bug converting java arrays when used as backing beans [RF-11680]
rich:fileUpload: A bug where the list of files in the event omitted the submitted files [RF-11744]
rich:extendedDataTable: removed cellpadding/cellspacing from EDT, replaced with appropriate CSS [RF-11759]

Please test drive this second release candidate, and give us your feedback in either the forums or with our issue tracker. We’ll soon have a 4.1.0.Final release we all can be proud of, for the work we put into it as a community!

RichFaces 4 CDK | jQeury UI Tabs

2011-11-29T15:26:00.001-08:00

Following on with another entry in my CDK series, this time we will look at at creating a pair of components to wrap the jQuery UI tabs plugin with the RichFaces CDK. It'll take two components to accomplish this; one component to define the tab container, and another to define the tabs themselves. Let's dive right in with a look at the Abstract component definitions.

As always, if you are interested in following along in your IDE, you can get the code below on github.

The Component Classes

AbstractTabs.java

package ca.bleathem.richfaces.jquery.component;

import org.richfaces.cdk.annotations.*;

import javax.faces.component.UIComponent;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

@JsfComponent(
        type = "ca.bleathem.richfaces.jquery.Tabs",
        family = "ca.bleathem.Tabs",
        renderer = @JsfRenderer(type = "ca.bleathem.jquery.TabsRenderer"),
        tag = @Tag(name="tabs"))
abstract public class AbstractTabs extends javax.faces.component.UIPanel {
}

Here we have the component class for tor the tabs tag - this will be the container for the tab components that follow. This is strikingly similar to the earlier AbstractHello component we saw in our first CDK example. The component class is serving as a placeholder to define the component properties (type, family, tag) , and the renderer associations. Look back through the previous blogs in this series if you don't recognize these properties.

AbstractTab.java

package ca.bleathem.richfaces.jquery.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.jquery.Tab",
        family = "ca.bleathem.Tab",
        renderer = @JsfRenderer(type = "ca.bleathem.jquery.TabRenderer"),
        tag = @Tag(name="tab"))
abstract public class AbstractTab extends javax.faces.component.UIPanel {
    @Attribute
    public abstract String getTitle();
}

The component class for the tab tag is similar to the one for the tabs tag, adding a definition for a title attribute, and with slightly different component properties. Let's move on from these mundane component definitions and look at the Renderers, where things get more interesting.

The Renderers
Looking first at the simpler tab renderer:

tab.template.xhtml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el"
        xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
        xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core"
        xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.jquery.renderkit.TabRenderer</cdk:class>
        <cdk:superclass>org.richfaces.renderkit.html.DivPanelRenderer</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.jquery.TabRenderer</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <div id="#{clientId}" class="rf_jq_tab">
            <cdk:body />
        </div>
    </cc:implementation>

</cdk:root>

This renderer is simple, again comparable to the hello.template.xml. The new piece we've introduced is the <cdk:body /> tag. This tag indicates where we want to render the contents of the component. So any content (or child components) we nest in out tab tag will be wrapped by the div tag.

We'll see this <cdk:body /> tag again when we look as the (slightly more complex) tabs renderer:

tabs.template.xhtml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el"
        xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
        xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core"
        xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.jquery.renderkit.TabsRenderer</cdk:class>
        <cdk:superclass>org.richfaces.renderkit.html.DivPanelRenderer</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.jquery.TabsRenderer</cdk:renderer-type>
        <cdk:resource-dependency name="" />
        <cdk:resource-dependency library = "javax.faces" name = "jsf.js" />
        <cdk:resource-dependency name = "jquery.js" />
        <cdk:resource-dependency library = "com.jqueryui/css/ui-lightness" name = "jquery-ui-1.8.16.custom.css" />
        <cdk:resource-dependency library = "com.jqueryui/development-bundle/ui" name = "jquery.ui.core.js" />
        <cdk:resource-dependency library = "com.jqueryui/development-bundle/ui" name = "jquery.ui.tabs.js" />
    </cc:interface>

    <cc:implementation>
        <div id="#{clientId}" class="rf_jq_tabs">
            <ul>
                <c:forEach items="#{component.children}" var="child">
                    <li><a href="##{child.clientId}">#{child.attributes['title']}</a></li>
                </c:forEach>
            </ul>
            <cdk:body />
        </div>

        <script type="text/javascript">
            jQuery(function() {
                $(document.getElementById('#{clientId}')).tabs();
            });
     </script>
    </cc:implementation>

</cdk:root>

This renderer template introduces a number of new concepts. For one, you might have noticed I didn't create a RenderBase class, like we did for the datepicker component. We could have, but I wanted to demonstrate that it's not strictly necessary. The CDK allows one to replace the @ResourceDependency annotations we used in the DatepickerRenderBase, with a CDK tag: <cdk:resource-dependency />. This is a one-for-one replacement for the annotation, with matching attributes (in fact, the CDK creates actual @ResourcesDependency annotations in the generated java code). This allows us to define all the required javascript and css resources required by the component in the renderer template itself.

We've also made use of the jstl core EL expressions to execute some logic in our renderer. You can see we loop over each of the children of the tabs component, which will be our tab components. For each child tab, we create an entry in an unordered list with the title attribute of the tab. This isn't just some arbitrary html, we are fulfilling the contract of the jQuery UI tabs plugin. The plugin is going to look for this specific markup to render the tab components, and attach the necessary behavior.

Following the unodered list, we see the <cdk:body /> tag. This renders the child components, delegating to the render associated with each child. In this case, the children are the tab components and will be rendered using the tab renderer from the above tab.template.xhtml template.

The last piece of this template is the javascript call, where we invoke the jQuery UI tabs plugin to enable the client-side behavior. We aren't passing any options to the plugin in this example, but we could easily do so using the scriptOption CDK tag demonstrated with the datepicker component.

The Result
So what does it look like when we put it all together?
With this sample markup:

<b:tabs>
    <b:tab title="Tab 1">
        Hello <b>Tab</b>!!
    </b:tab>
    <b:tab title="Tab 2">
        With nested components:
        <br />
        <b:datepicker value="#{myBean.value}" dateFormat="yy-mm-dd" showOn="both" buttonImageOnly="true" /> <br />
    </b:tab>
</b:tabs>

We can see we have multiple tabs, and for kicks I nested the datepicker component from the previous CDK entry.

So here it is, the jQuery UI tabs plugin wrapped with the RichFaces CDK, providing us with a bare-bones tab component. A lot more work is required to get this to a point where it could replace the RichFaces tab component, but we have succeeded in creating a functional component leveraging existing javascript code, and without a lot of work on our part.

RichFaces 4.1.0.CR1 Release Announcement

2011-11-23T10:10:00.000-08:00

I’m excited to announce the availability of RichFaces 4.1.0.CR1, the first release candidate for RichFaces 4.1.0. Stability of the platform has been a strong focus for all the RichFaces 4.1.0 milestone releases, and has been even more so of a focus for our CR1 release.

We really appreciate the community feedback we’ve received throughout the 4.1 development cycle, with each of the milestone releases. The bugs found and the suggestions provided from the community have really helped us nail down this release. As such, we are encouraging everyone to download this release candidate, and help us flush out any regressions or other potential blocker issues. Let us not forget, "given enough eyeballs, all bugs are shallow"!

To try out this release, you can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.1.0.20111111-CR1. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

With that “call to arms” out of the way, let’s take a look at what’s changed in this release.

Mobile Compatibility
We have been working on the RichFaces mobile guide, and will have it available shortly - watch for it the RichFaces wiki. Refer to this guide to take advantage of the mobile compatibility of the RichFaces components in our mobile showcase as we presented at a recent JBoss webinar (video of the webinar is available). The CSS and javascript we used in our mobile showcase has been cleaned-up and refactored, and ready for public consumption, with details of how to do so in the mobile guide.

We've also improved the mobile compatibility of some individual components, such as the calendar component (specifically the time picker), and the rendering of the pickList buttons. Thanks to the community members who pointed these deficiencies out!

Documentation
The Component Reference and Developer Guide have been updated for this release candidate, in preparation for the upcoming final release. In addition, a bug in the automatic generation of the VDL-DOC (tag library docs) has been addressed, once again providing a complete listing of all RichFaces components’ attributes. The latest javadoc has also been published.

Many of the attribute descriptions themselves in the VDL-DOC still need to be filled out (pull requests here would be very welcome!) - so be sure to refer to the Component Reference to supplement the VDL-DOC.

Framework upgrades
We upgraded our client-side bean validation extension to use Hibernate Validator 4.2, aligning with what is currently shipped in JBoss AS 7, and with what developers will be using with their applications. We also changed the project compiler compatibility to Java SE 6.0, reflecting in reality what has been true for the project for some time. We also started verification of the RichFaces platform against the upcoming JBoss AS 7.1 release, aiming for a smooth transition for RichFaces applications when AS 7.1 is released.

Individual improvements
Individual components have seen some improvements with this release. Ajax rendering of drag sources and drop targets has been improved, tab panel switching across the client/server has been cleaned up, and the tooltip was changed to better respect the value attribute for delivering the tooltip message. In addtion to these individual fixes, we addressed a number of IE8 compatibility issues.

Onward to Final
Unfortunately, we’ve have introduced some regressions with this release, namely with the calendar component and table sorting/filtering. These issues have already been addressed in our development branch, and will be ready for the upcoming final release.

Be sure to give this release a spin, and help us make 4.1.0.Final a top-notch release!

RichFaces 4.1.0.M4 Release Announcement

2011-11-09T09:35:00.000-08:00

The RichFaces 4.1 Milestone 4 release is now available for download! With this M4 release we focused on stabilizing the features we introduced in the earlier 4.1 release-train milestones (M1, M2, M3). The release following M4 will be our 4.1 release candidate, so we want to make sure we achieve maximum stability with M4. Some of the key areas we touched are listed below.

If your keen and want to get started right away, you can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.1.0.20111101-M4. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Mobile showcase improvements
The CSS 3 overlay was improved to provide better mobile compatibility of the components. We also added an ajax status indicator to the mobile showcase. Since it is entirely an ajax driven application, the status indicator improves the user experience dramatically.

Resource mapping
The resource mapping feature introduced in M3 has been made more usable, adopting a consistent naming convention, with reasonable defaults. Additionally the ability to completely disable the feature was introduced, should you want to handle resources yourself in your applications.

Client Side validation
Improvements to the client-side validation (CSV) involved better aligning the client-side regexp with the Bean Validation specification. The CSV mechanism for discerning component values on the client (using javascript) was enhanced to improve the CSV interop with other JSF component providers.

Individual component fixes
The file upload component has some new attributes, allowing for more fine-grained control over what the user is able to upload to the server. The pickList saw the switchByClick and switchByDblClick functionality from RichFaces 3 ported to RichFaces 4, further improving the RF 3 to RF 4 migration story.

Misc. Fixes
Some additional issues resolved include a jQuery update (to version 1.6.4), and improvements to both the simpleapp and GAE RichFaces archetypes. Many more fixes and improvements were checked, feel free to browse the issues fixed to see what else has been improved.

Forward: CR1 & Further Stabilisation
The CR1 development is currently ongoing, with a focus on providing documentation for all the new 4.1 features, and further stabilisation. So give M4 a spin, and let us know what you think! Drop a note in the forums, or join us for our weekly community/team meetings in IRC.

RichFaces 4.1.0.M3 Release Announcement

2011-10-27T10:36:00.000-07:00

The RichFaces 4.1 Milestone 3 release is now available for download. Further building on the new components and framework improvements introduced in the M1 and M2 releases, M3 brings it all together with an improved showcase - featuring a demonstration of the mobile compatibility of the RichFaces 4 component set. Along-side improvements to resource handling, and enhancements to the push component, we’ve fixed a number of bugs and issues, as voted by you - our user community!

Showcase - Going Mobile

The showcase as seen on mobile
devices (using device detection)

The showcase has received some attention in this release. First and foremost we’ve demonstrated the mobile compatibility of the existing component set with the addition of some simple css and javascript resources (using a well vetted approach).

The mobile showcase in RichFaces is a an initial mobile effort, focusing on making the existing RichFaces components work within mobile browsers. While not a full-blown set of mobile components, we’ve tweaked the framework as necessary and put forward the mobile showcase as an example of how you can make your existing RichFaces applications mobile-friendly with the current RichFaces component set. Stay tuned for an upcoming blog entry with details on how you can take advantage of this in your own applications. Or, if you’re feeling adventurous, have a look at the showcase code to see how we did it!

Showcase - On OpenShift
We've deployed the showcase application to OpenShift -- the PaaS offering by Red Hat. The OpenShift Java EE 6 support provides a great platform to take your application all the way from development with Express (free!) to production with Flex (highly scalable!). Express is a shared multi-tenant environment made to be as simple as possible to get started quickly, while Flex gives you dedicated VMs and DevOps control over architecture along with monitoring. For the RichFaces project, this gives us the chance to showcase our components in a Java EE environment, where our framework really shines!

(Note, until 4.1 is released, the showcase at http://richfaces.org/showcase will continue to demonstrate the RichFaces 4.0 framework and components).

Showcase - New Component Samples
Additionally we’ve added some polish to the showcase with bug fixes and user experience tweaks, and we've included samples of the latest RichFaces components. You will now find showcase samples for the rich editor, notify, orderingList, and pickList components, complete with samples showing you how to put them to good effect in your applications.

Resource handling
Along-side these showcase improvements, we’ve introduced framework improvements to improve the mobile experience. With the new RichFaces 4.1 Resource Handling features, we are packaging and minifying the out of box JavaScript and CSS. This is in an effort to reduce HTTP requests made by the framework and to give mobile apps (or any app) a boost in performance. For those familiar with RichFaces 3, this also brings back the old LOAD_ALL configuration, albeit with a new name. We’ll have a blog post out shortly, with details on how you can try these features out with the Milestone 3 release.

Ajax Push
Last (and by no means least!) I’d like to mention that the AJAX push component has seen a lot of improvements with this release. We’ve introduced a CDI interface for firing push events. This is not intended to supercede the existing Push API, but is instead provided as a means to tie the powerful CDI event mechanism into the RichFaces push technology.

Coupled with earlier push improvements (removing the JMS requirement from the push component), the push component is shaping up to be much more accessible to developers working in either Java EE or Servlet container environments.

Forward: M4 & Stabilization
Work is already well underway with our M4 release, where we are improving on the compatibility of our components with mobile browsers, and adding a last round of small feature improvements. Give M3 a spin, and let us know what you think! Drop us a note in the forums, or join us for our weekly community/team meetings in IRC.

RichFaces 4 CDK | jQuery UI Calendar

2011-10-07T03:55:00.000-07:00

Further incrementing the complexity over the input component we created previously, this time we will create a JSF calendar component. Being pragmatic OSS developers, we will leverage the existing javascript of the datepicker component from the jQuery UI project, and we'll see how well the RichFaces CDK lends itself to mapping JSF component attributes into javascript configuration options.

As always, if you are interested in following along in your IDE, you can get the code below on github.

The Component Class
Starting again with the component class:

AbstractDatepicker.java

package ca.bleathem.richfaces.jquery.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.jquery.Datepicker",
        family = "ca.bleathem.Datepicker",
        renderer = @JsfRenderer(type = "ca.bleathem.jquery.DatepickerRenderer"),
        tag = @Tag(name="datepicker"))
abstract public class AbstractDatepicker extends javax.faces.component.UIInput {

    @Attribute
    public abstract String getDateFormat();

    @Attribute
    public abstract String getShowOn();

    @Attribute
    public abstract String getButtonImageOnly();

}

Here we see we are again extending the UIInput class, as we did with the Input component. What's new is the introduction of some additional attributes. The @Attribute annotation instructs the CDK that these abstract getter methods map to component attributes, and the CDK then takes care of wiring the attributes into the JSF state saving mechanism for us.

The naming convention of the attribute is alligned with jQeury UI datepicker options. This allows us to transparently pass the JSF component attributes through to the jQuery plugin, as we see in the Renderer below.

The Renderer
The renderer is again an xml file:

datepicker.template.xml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el" xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
    xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core" xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.jquery.renderkit.DatepickerRenderer</cdk:class>
        <cdk:superclass>ca.bleathem.richfaces.jquery.renderkit.DatepickerRendererBase</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.jquery.DatepickerRenderer</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <input type="text" id="#{clientId}" name="#{clientId}" class="rf_jq_cal" value="#{getInputValue(facesContext, component)}" />
        <script type="text/javascript">
            <cdk:scriptObject name="pluginOptions">
                <cdk:scriptOption name="buttonImage" value="#{getResourcePath(facesContext, 'ca.bleathem', 'calendar.gif')}" />
                <cdk:scriptOption attributes="showOn dateFormat buttonImageOnly" />
            </cdk:scriptObject>
            jQuery(function() {
                $(document.getElementById('#{clientId}')).datepicker(#{toScriptArgs(pluginOptions)});
            });
	    </script>
    </cc:implementation>

</cdk:root>

Diving first into the cc:implementation of this renderer template, we see again an input element. What's new is the script tag following the input. This script tag get's compiled into javascript when the component renders. Using CDK xml markup, we build up the javascript object pluginOptions which we pass as a parameter to the call to the jQueryUI plugin.

The document.getElementById('#{clientId}') is a workaround for JSF's use of the ":" character in javascript IDs - this doesn't play well with jQuery. By first calling document.getElementById, we end up with an argument that is acceptible to jQuery. Notice the #{toScriptArgs(pluginOptions)} argument to the datepicker jQuery UI plugin. This initializes the datepicker plugin, with the JSF component attributes specified by the application developer.

From the cc:interface of this renderer template, we see that we are extending the class DatepickerRendererBase. This class is included below:

DatepickerRendererBase.java

package ca.bleathem.richfaces.jquery.renderkit;

import org.richfaces.renderkit.InputRendererBase;

import javax.faces.application.ResourceDependencies;
import javax.faces.application.ResourceDependency;

@ResourceDependencies({
        @ResourceDependency(library = "javax.faces", name = "jsf.js"),
        @ResourceDependency(name = "jquery.js"),
        @ResourceDependency(library = "com.jqueryui/css/ui-lightness", name = "jquery-ui-1.8.16.custom.css"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.core.js"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.widget.js"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.datepicker.js"),
        @ResourceDependency(library = "ca.bleathem", name = "calendar.gif")
})
public class DatepickerRendererBase extends InputRendererBase {
}

The DatepickerRendererBase class is again extending the InputRendererBase, and it is holding a number of @ResourceDependency annotations. These annotations ensure the appropriate resources are included on the page when we reference this JSF component. For us, these resources are the jQuery UI plugins necessary to get the datepicker component working.

Introducing an entire new class merely to hold the @ResourceDependency annotations may seem like overkill, but in any reasonably complex component, we will end up putting some renderer helper logic into this class file. There are times when the expressivity of Java works better than the declarativity of xml. We'll see some of this later in our blog series.

Finally, let's look at en example use of this component:

sample.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:b="http://bleathem.ca/test"
      >

<body>
<ui:composition template="/templates/template-jqueryui.xhtml">

    <ui:define name="title">Datepicker Sample</ui:define>

    <ui:define name="body">
        <h:form>
            <b:datepicker value="#{myBean.value}" dateFormat="yy-mm-dd" showOn="both" buttonImageOnly="true" /> <br />
            Input value: <h:outputText value="#{myBean.value}" /> <br />
            <h:commandButton value="Submit" action="null"/>
        </h:form>
    </ui:define>
</ui:composition>
</body>
</html>

When rendered, this looks like:

Screen shot

While this has certainly grown in complexity over our initial HelloWorld component, we've managed to keep our JSF component development DRY. We've leveraged existing, high-quality javascript components. We've also made use of the RichFaces CDK to wire the JSF configured component to the javascript object. Some additional work is required to continue mapping the jQuery UI datepicker plugin options into JSF component attributes, but the mechanism for this has been laid out, and completing the component will be quite straight forward (pull requests welcome!).

In my next CDK installment, we'll look at creating a layout based component, rather than an input component. Stay tuned!

Testing AS7 web apps over SSL

2011-10-05T20:01:00.000-07:00

Here's a recipe I found useful for trouble-shooting a web-app over an SSL connection. The steps involved are to:

Set the server name/IP on each of the testing machines (both Windows and Linux)
Create a self-signed certificate for the server using the java-based keytool
Export the certificate for installation as a CA in the clients
Configure JBoss AS7 to use the certificate sotre

All the above steps are sufficiently simple, but each required it's own share of googling to get everything just right. This post is as much a set of notes to myself in the future, as it is a blog.

1. Setting the Server name

On your Linux testing machine, make sure the sure IP and name of your local server are in your /etc/hosts file:

127.0.1.1 bleathem-redhat bleathem-redhat.local

Do the same thing for you windows clients - that's right! Windows has a /etc/hosts file! See this wikipedia article to locate the file in your version of windows.

2. Create a self-signed certificate
Use the java keytool command to create the certificate store:

keytool -genkey -alias tomcat -keyalg RSA -validity 3650 -keystore server.jks

when asked for your "first and last name", answer with the fully-qualified domain name. For me this is bleathem-redhat.local.

3. Export the certificate
Export the certificate from the keystore you just created, again using the keytool command:

keytool -exportcert -alias tomcat -keystore server.jks -file as7.cer

Copy this certificate to your Windows clients, and install it as a certificate authority. I found this to be necessary, as IE9 is particularly nasty about dealing with "unofficial" certificates. Steps to do this are left as an exercise for the reader! (I don't feel like taking a bunch of windows screenshots.)

4. Configure JBoss AS7
In the standalone.xml configuration file of your AS7 instance, find the line:

<connector name="http" protocol="HTTP/1.1" socket-binding="http" scheme="http"/>

And add below it the lines:

<connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" secure="true">
    <ssl name="https" password="changeit" certificate-key-file="standalone/configuration/server.jks"/>
</connector>

This will configure your AS 7 instance to use your newly created certificate store on it's SSL enabled port. The default https port for AS7 is 8443.

And there we have it! A fully functional SSL/https enabled environment for testing our web apps!

RichFaces 4 CDK | Input Component

2011-09-21T12:14:00.000-07:00

With our last component, we saw how we could output some simple text with a custom JSF component created with the RichFaces CDK. Let's increment the complexity, and see how we can create a component that accepts input. Again, the goal here is to highlight how the important features fit together, and to leverage as much of the plumbing work as possible from the RichFaces CDK.

If you are interested in following along in your IDE, you can get the code below on github.

The Component Class

In a similar approach to our Hello World component, we'll start with the component class for our Input component:

AbstractInput.java

package ca.bleathem.richfaces.input.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.input.Input",
        family = "ca.bleathem.input",
        renderer = @JsfRenderer(type = "ca.bleathem.input"),
        tag = @Tag(name="input"))
abstract public class AbstractInput extends javax.faces.component.UIInput {

}

This looks pretty similar to the component class for the Hello World component, with an appropriate changing or type, family, renderer and tag. One significant change to take note of is the base class for the component. Notice how we are extending the UIInput class. This allows us to leverage the value holding and state saving that has already been built into this component. No matter what kind of UI you want to build for your component, you will almost always want to store a single value (we'll discuss select many components in another post). So extending UIInput is generally a good idea.

The Renderer

The corresponding renderer template for our input component is:

input.template.xml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el" xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
    xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core" xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.input.renderkit.InputRenderer</cdk:class>
        <cdk:superclass>org.richfaces.renderkit.InputRendererBase</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.input</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <input type="text" name="#{clientId}" value="#{getInputValue(facesContext, component)}" />
    </cc:implementation>

</cdk:root>

Again, this looks pretty similar to the template for the Hello World component. The key difference being the Renderer superclass, and the html markup in the cc:implementation. By extending the RichFaces InputRendererBase class, we save ourselves from having to write the logic to decode and invoke the validators for our component. Again, this is something we will want to do for many of the components we write.

The html markup is also rather simple. By giving the input element the name of our component ID, we are indicating which form component should be decoded when the component is processed. When authoring a component with a complex UI, you will often make this input element a hidden input type, to store and submit your value while not interfering with your UI. We'll see more of this in later entries of this CDK series.

I'll also add that the package-info.java file described in the Hello World entry is still required, if you don't already have one included in your jar.

And that's our input component - again done as simply as possible. The next entry will wrap an existing jQuery UI component, showing how the CDK is an effective means to leverage the work others have already put in to authoring complex javascript components.

RichFaces 4.1.0.M2 Release Announcement

2011-09-21T09:03:00.000-07:00

The Richfaces 4.1 milestone releases are trucking along. With M1, we had a focus on changes surrounding project infrastructure, and the introduction of some new components. Now with M2 we see updates to the core, and a stabilization of both the new components and the framework as a whole.

jQuery Upgrade

We built the RichFaces 4 components using jQuery for DOM manipulation. Given the degree to which the we rely on jQuery, upgrading it is a "big deal". In order to ensure none of our components break during this milestone release, both our QE and Dev teams have been busy tending to our test infrastructure. The benefit of shipping with the latest jQuery is that it provides better compatibility to application developers wishing to leverage cutting edge jQuery plugins, or integrate with other component libraries.

IE9 support
As part of our extensive testing of our platform, we noticed a number of compatibility issues with Internet Explorer 9 running in strict or normal mode. We isolated this as an upstream issue, and will work with the Mojarra team to patch the underlying problem. In the mean-time, the issues can be worked-around if you run IE 9 in compatibility mode.

Stabilization of the new components
The new components introduced in M1 have benefited from further development, and constructive user feedback (thanks!).

rich:editor
The Editor has several new features, but the most valuable is the integration with the standard RichFaces styling scheme. Further details are available in Lukas’ blog post.

rich:notify
Notify Messages have been better integrated into the RichFaces ecosystem, allowing them to consume Client-Side Validation messages. The Notify Stack was also refactored - this is where one configures the location and orientation of messages.

rich:pickList
The Pick List has picked up ordering capabilities in the target list, making it now a viable replacement for the older listShuttle from RichFaces 3. In addition, the Pick and Ordering Lists have exposed more events, allowing for applications to better hook into their behavior.

Face-to-Face
A fair chunk of time during the M2 sprint was spent by the team in a face-2-face meeting, where our world-wide development team came together to discuss the future of the project. Stay tuned for updates along these lines, as we distill our ideas and engage the community for feedback to collectively define our project vision and future.

Forward: M3 and mobile
As always, we've taken care of a number of bug fixes with the M2 milestone release. However, the upcoming M3 release is when we will buckle down and focus on taking care of stabilizing the platform as a whole, and fixing as many bugs as we can, particularly in the mobile space. To help us better identify where we would best be spending out attention, please get on Jira, and vote for the issues that are important to you.

RichFaces 4 CDK | Hello World

2011-09-10T00:12:00.000-07:00

This is the first technical post of my CDK series. Starting real simple, we'll create a component that produces a hello world output. "Why start with a hello world? Isn't that a little cliche?". Well indeed it is, but it is by far the best way to point out the fundamental pieces of the CDK, and how they together. We'll build a strong foundation in our understanding of the CDK, on which we can build more interesting components in future posts.

If you are interested in following along in your IDE, you can get the code below on github.

The Component Class
To start, we need a component class. The component class itself will be generated by theRichFaces CDK. However we do define a base class from which the generated class will extend. We'll see why this is the case when we get to more complex components. But for now, let's start with this base class:

AbstractHello.java

package ca.bleathem.richfaces.hello.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.hello.Hello", 
        family = "ca.bleathem.text", 
        renderer = @JsfRenderer(type = "ca.bleathem.hello"), 
        tag = @Tag(name="hello"))
abstract public class AbstractHello extends javax.faces.component.UIComponentBase {

}

Here we have an abstract class annotated with @JsfComponent. This annotation marks the class as a CDK class, and will be consumed by the CDK pre-processor. The CDK uses the attributes of the annotation to construct the necessary classes, and the necessary xml configuration. Creating JSF components is verbose, but we don't have to worry about the verbosity - the CDK takes care of it for us!

Let's look more closely at the @JsfComponent annotation, and the meaning of each of it's attributes. I'll start by pointing out that the annotation supports many more attributes, but we are only covering here the bare minimum required to get a simple hello world component created.

type: the value of the type attribute is how JSF identifies out component. It will be used in the generated faces-config file, and in the generated xml taglib file.
family: the value of the family attribute is used by JSF to recognize "like" components. We'll get into details of this in future posts. This attribute is in fact optional, and the value can be generated by naming conventions. However, I prefer to specify it explicitly.
renderer: the value of the renderer attribute is used to match our component to an appropriate renderer. We'll create the renderer next!
tag: the value of the tag attribute will be the actual facelet tag that we use in our facelet files.

The last aspect of out component class that I want to point out is the "extends UIComponentBase" part. Every JSF UI component must extend this class, or one of it's descendants. We'll be able to save ourselves alot of work when we get to more complex components, by judiciously choosing the right class to extend.

The Renderer

Next, let's look at the JSF Renderer:

hello.template.xml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el" xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
    xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core" xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.hello.renderkit.HelloRenderer</cdk:class>
        <cdk:superclass>javax.faces.render.Renderer</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.hello</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        Hello World! (from a RichFaces CDK component)
    </cc:implementation>

</cdk:root>

If you are familiar with JSF Component development, you may be surprised to see that our Renderer is not a java class. On the other hand, you may find that it looks quite similar to a JSF 2 composite component. It has a "<cc:interface>" section, and "<cc:implementation>" section, both of which are analogous to the facelet file of a composite component. In fact, you can prototype your components as composite components, then migrate to CDK components when you find you need the extra flexibility the CDK provides.

As we did for the component class, let's dissect the cdk tags found in our renderer template.

<cdk:class>: this is the name of the JSF Renderer class that will generated.
<cdk:superclass>: the class that will be extended by our generated JSF Renderer class. Here we are explicitly stating the default for reference when we get into more complex components.
<cdk:renderer-type>: this is how JSF identifies our Renderer. It will be used in the generated faces-config file, and in the generated xml taglib file.

And there we have it, a JSF Component, and it's associated Renderer! -- err almost. There is one final piece missing. We need to specify a name space for our component - the namespace that will be used on facelet pages that refer to our components. Fortunately, the CDK also makes this easy for us. All we need is a package-info.java in the java package of our component:

package-info.java

@TagLibrary(uri="http://bleathem.ca/test",shortName="testLib")
package ca.bleathem.richfaces.hello.component;
import org.richfaces.cdk.annotations.TagLibrary;

Here you can see the @TagLibrary annotation that specifies the namespace of our component.

Now we can build a jar, include it in our application, and use our hello world component! Go ahead and run the build. If you are curious, take a look in the target/generated-sources folder. There you'll see all the JSF classes and xml files that the CDK generated for us. Those are all classes and xml files we would have had to write ourselves if we weren't using the CDK.

Well, a hello world JSF component - not really useful... but there is more coming! The next entry in this series will use the CDK to create an input component, and from there we'll get into some more sophisticated components!

In closing, I want to add that the CDK is incredibly flexible, and there all multiple ways the above component could have been put together. I'm sticking to what I think is simplest, most clear, and most extensible.

Seam Faces Community Hack Night

2011-09-07T22:16:00.000-07:00

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!

RichFaces 4 CDK | Introduction

2011-08-31T18:45:00.000-07:00

A new blog series

Having recently dived head first into the RichFaces 4 Component development Kit (CDK), I thought it would be useful to share the knowledge and experience I've gained. Over the next few weeks, I am going to put out a series of blog posts giving some examples of how to use the RichFaces CDK. Hopefully by the end of this series, we will have written some interesting components and left you with the urge to write your own JSF components using the CDK!

Before I get into specific examples, I’d first like to motivate the series by describing what exactly the CDK is and the problems that it solves. If you already know all about JSF components, and you want to get straight into using the CDK, skip this blog post! - the rest of the entries in this series will deal purely with implementation details.

What is the RichFaces CDK anyway?

JSF was designed to make components easy to consume. The syntax is very html-like, and EL makes it easy to bind components to backing beans. However, writing JSF components has traditionally not been very accessible. With the number of classes that one has to create and wire together, along with a requirement for detailed knowledge of the JSF API, components were typically left to third party component suites, like RichFaces, IceFaces and Apache. Things were improved drastically with the release of JSF 2.0, and it’s support for composite components.

Composite components let the user build JSF components purely in xhtml - without requiring any lines of Java. This is a fantastic improvement, as developers can build their own re-usable components that encapsulate a fair amount of complexity and keep their applications DRY. An overall bonus indeed! While composite components achieve a lot, the mechanism falls short when it comes to creating full-fledged JSF components.

The concise and non-java nature of composite components that makes them so appealing, is also their biggest limitation. Oftentimes one needs additional expressivity not available in EL, or one needs to tap further in to the JSF lifecycle. Thus in JSF 2, the component suite providers find themselves once again writing components in Java, to be able to take advantage of the rich APIs that JSF provides.
This is where the RichFaces CDK comes in. The RichFaces team provides the CDK as a means for developers to write JSF components with many of the simplifying advantages of the JSF 2 composite components, but also with the full power and flexibility provided by the JSF component APIs.

JSF Components simplified with the CDK

To understand how to use the CDK, one first has to understand how JSF components are put together. At the end of the day, JSF components are built out of Java classes, and the CDK is simply an effective means to generate those classes.

To build a JSF component, one starts by extending the UIComponent class. This class defines the attributes and API of your component and is responsible for hooking into the JSF state saving mechanism. While you could put your rendering code into this component class itself, you’re better off putting that rendering code in a separate Renderer class. You’ll also end up writing a TagHandler class to couple the Render and component. And should your component fire FacesEvents, well you’ll need to implement additional interfaces and provide more classes. Lastly you’ll need to register these classes in the faces-config.xml and provide a taglib.xml file. Now there’s a mouthful!

The CDK simplifies this all for us, by generating a lot of the above code. All we need to create when we use the CDK is a component base class, and an xhtml file to define the rendering behaviour called the “Renderer template” . This Renderer template is designed to build on the JSF 2 composite component mechanism, so if you can build JSF 2 composite components, you’re already half-way there!

With the component base class, the Renderer template, and the annotations that couple them, the CDK is able to generate the rest of the required files for us. There is nothing sub-standard about these generated classes - they are full-fledged JSF components in every way! In fact, much of the RichFaces 4 component suite is built using the CDK!

There is a lot of detail to cover in how to write the component base class, and the accompanying Renderer template. I’ll begin covering these details in my next post, where we will write a “Hello world” JSF component using the CDK. But if you can’t wait for my post, feel free to dive into the RichFaces CDK docs.

RichFaces 4.1.0.M1 Release Announcement

2011-08-16T10:09:00.000-07:00

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

2011-08-16T09:53:00.001-07:00

(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

2011-06-17T08:32:00.000-07:00

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

2011-04-18T07:43:00.000-07:00

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:

Restricting view access by integrating with Seam Security
Configuring URL rewriting by integrating with PrettyFaces (or any other pluggable URL rewriting framework)
Configuring Transactions via Seam Persistence
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

2011-04-03T20:44:00.000-07:00

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

2011-03-27T22:03:00.000-07:00

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

2011-02-16T19:15:00.001-08:00

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.

RESTful URLs, with JSF 2

2011-01-29T11:33:00.000-08:00

JSF 2 introduced the ability to create RESTful URLs with the introduction of the <f:viewParam> tag. The tag is easy enough to use, you simply place it in the <f:metadate> tag, and configure the attributes to decode the url.

<f:metadata>
     <f:viewParam />
</f:metadata>

There are no words to explain how great a feature this is for JSF. The old "every request is a POST" theory didn't pan out. RESTful URLs are bookmarkable, and meaningful to end-users. Unfortunately they are still a bit tricky to use in vanilla JSF, as there are only three backing bean scopes in "vanilla" Java EE 6 that are capable of dealing with business transactions/conversations, and each currently has it's own set of limitations. They are the Session, Conversation, and View scopes

First the Session scope - don't use it! The Session scope is essentially global for your user as they interact with your web application; there is no concept of a business conversation. In short, you'll end up with a scalability issue as your session fills up with business objects that are no longer relevant to the current user task.

The second scope to consider is the Conversation scope introduced in Java EE 6 with CDI. It can span multiple requests, but is shorter lived than the Session. It at first seems great, but if you're not careful, it breaks the concept of RESTful URLs by tagging the nasty little "cid=#" parameter to your query string. If the user bookmarks, or otherwise shares the URL, a conversation expired exception will be thrown when the URL is later reloaded. This quickly becomes a burden to try and deal with. This *is* something that is fixed with Weld 1.1, but I've got apps to write today!

Finally, this leaves the View scope introduced with JSF 2. The lifetime of the bean is tied to the JSF view - ie. your bean falls out of scope when you navigate to a new view. The short, well defined nature of this scope means you don't have the memory leak problems of the Session scope, and it doesn't mess up your RESTful URLs the way the Conversation scope does. However, the only way to get View scoped beans to to share information between views is by using viewParams. So if you store your business data in View scoped beans, you have to persist your data before moving on to the next view. This is how I currently build my applications, but the views are becoming too cluttered with javascript panels and popup boxes, as I try to fit a complete business conversation in a single view.

I'm very hopeful that with Weld 1.1, and the fix of issue WELD-549, that I will be able to make better use of Conversation scoped beans. I will the be able to navigate between URLs (with faces-redirect=false) with conversation scoped beans, and not have to worry about the "cid=#" parameter showing up in my URLs when the user performs navigations not relevant to the current conversation. At least hopefully this will be the case!

Additionally and/or alternatively, we need more scopes. Something like the ViewAccess scope I last blogged about, where the developer doesn't have to think about bean scope so much. Just write your app, and have the framework do the right thing.

Please share your thoughts if you've got another way of working with RESTful URLs in your JSF apps, I would love to hear about it!

ViewAccessScope - why it's useful

2010-12-17T10:51:00.000-08:00

At first the conversation scope introduced with CDI seemed like it would be incredibly useful. Unfortunately, working with conversations ended up being more difficult than expected. Details of why this is, is fodder for another post.

I ended up often using the JSF ViewScope, exposed as a CDI scope though the Seam Faces CDI extension. When used in conjunction with JSF viewParams to propagate information between pages, the result is a book-markable end user experience.

The problem with this is that the "business conversation" is now restricted to a single page. JSF components that provide a tabbed interfaces allow one to pack a lot into a single page, in a clear and structured way, but there are times when it just makes more sense to navigate to a new page (or view in JSF speak).

This is where the ViewAccessScope comes in. It's a scope defined in MyFaces CODI (a CDI extension). The ViewAccessScope is like a long-lived conversation, where the conversation ends as soon as you use a view that does not reference the ViewAccessScoped bean.

The pattern I see as being incredibly useful, is to initiate a "business conversation" by passing viewParams to a page, then navigate through appropriate views to complete the process. When we come to a page that no longer references the ViewAccessScoped bean, the business conversation is over. This is a perfect fit with how I think of structuring my apps.

Now to try it out, and see how well it works!

CDI does events too!

2010-11-20T14:06:00.000-08:00

CDI is the new programming model introduced with Java EE 6. An acronym for Contexts and Dependency Injection, CDI advertises well two of the programming paradigms it aims to solve. But there is another, often overlooked sibling: Event handling. While I'd heard it mentioned in the context of CDI, I'd never really paid much attention - I was probably too busy trying to wrap my head around Conversations, and how CDI provides Dependency Injection. And me being me, once I learn something cool, I have to tell everyone who will isten all about it!

Adam Bien does a fantastic job introducing CDI events in his blog entry. There are only three really noteworthy lines of code that I will repeat here:

@Inject Event events;
events.fire(new HelloEvent(...));
public void listenToHello(@Observes HelloEvent helloEvent){ ... }

These three lines are all that's required to produce and observe the event. Anyone who's programmed with Swing knows the benefit of decoupling concerns with action events and action listeners. This is the same thing, only far more elegantly implemented.

One of distinguishing points for me is the POJO nature of the events. With nothing to extend or implement, they can be as simple or as complex as necessary. All without the loss of (compile-time) type safety, due to the generic implementation.

Well done guys, CDI just got that much better for me!

My Glassfish support subscription came through - finally

2010-07-15T13:10:00.000-07:00

Call me eager, call me insane, I had a JavaEE 6 app up and running in production on Glassfish 3.0 one month after it's release. The improvements in JSF 2 and CDI were too compelling for me to hold off adopting, and sure enough, the application was quick and painless to develop.

I did however pay a price for being an early adopter - a Glassfish / Weld bug was preventing my JSF login pages from working. Fortunately I was able to quickly find an (ugly) workaround to get me going using JSPs. This brings me to the interesting nugget of this post: the story of my first use of our Glassfish v3 support contract.

I promptly reported the bug to Glassfish, using the support tools provided, and was overall impressed at how quickly the bug was isolated, and a resolution was found. All I had to do was wait for the patch, and my problem would disappear. So I waited for the patch. And waited. And waited...

I reported the bug in January, and heard of a fix in February. The patched release was supposed to come out in March. By May, there was still no release. I made a little noise, and got some attention from both Glassfish support, and the Glassfish Community, but was told the release was delayed by Oracle buying Sun, and the associated "Change in Control". I was however assured that the release was imminent.

Sure enough, Glassfish 3.0.1 was released June 17th, with the fix to my bug - a turnaround of 5 months. While annoyed that I had to wait so long for the fix, I do appreciate having that support structure in place to ensure we get our apps working. I'm just glad we had a workaround.

Here's to looking forward to a regular release schedule for Glassfish patches!

JSF Validation Failed Notice

2010-06-25T10:20:00.000-07:00

Here's how I show a notice on a JSF 2 page indicating that the JSF 2 postback failed due to validation errors. The following facelet snippet is rendered only when validation fails:

<h:outputtext 
   styleclass="errorMessage globalMessage" 
   value="Request *not* saved due to input errors" 
   rendered="#{facesContext.validationFailed}" />

The user then knows they should look through the page to correct the individually marked validation failures.

From svn to mercurial, the hg rises!

2010-04-09T20:03:00.000-07:00

I've been toying with the idea of moving from svn to a distributed version control system (dvcs) for a long time. I held back, hoping the mercurial (hg) vs. git "war" would declare a winner, but as major projects started adopting the two dvcs's, it became apparent to me that neither tool was going to disappear anytime soon. This notion was cemented for me when I read a forum post saying

hg = git >> svn

That settled it. I had to pick one, and move forward. I chose mercurial, not because it stood out above git, but it seemed to be more widely adopted in the communities I was interested in. Joel Spolsky's mercurial primer settled it for me. Mercurial was on it's way in. I had identified identified some key obstacles I needed to overcome to replace my subversion infrastructure with a new mercurial one. I had to figure out:

How to install hg in CENTOS 5
How to import the revision history from svn into hg
How to get LDAP authentication to work with hg
How to integrate hg with hudson (our continuous integration server)
How to get the maven release plugin to work with hg

These were all things I'd achieved with subversion, so they set the bar I had to achieve with any subversion replacement. Each of these steps turned out to be pretty easy overall. I ended up completing the process with a single days work (or two half-days...)

1) Install mercurial in CENTOS 5

I hunted around for a while looking for an RPM, but found nothing recent. On a twitter recommendation, I tried installing from source. Turned out to be pretty easy. The install ended up putting mercurial in my /usr/local/lib64 directory, which is not one of the default places python looks for it's modules. I had to do set the PYTHONPATH environment variable pointing to this directory to get things to work.

2) svn import into hg

Turns out mercurial has this functionality built in with the bundled Convert Extension. One has to enable this extension in a mercurial configuration file, then it's pretty simple to point the "hg convert" command at your subersion repo. Done and done!

3) LDAP integration

I'd achieved svn LDAP integration using apache, so I was quite happy to see hg did the same thing. I set up the hgwebdir.cgi script to serve my newly imported hg repositories, hi-jacking the LDAP authentication from my svn setup. Worked like a charm.

Update, here's the apache config for authentication:

# cat /etc/httpd/conf.d/hg.conf
ScriptAlias /hg "/var/www/hg/hgwebdir.cgi"


        Order deny,allow
        Deny from all
        Allow from 10.0.0.1
        AuthType Basic
        AuthBasicProvider ldap
        AuthName "LDAP password"
        AuthLDAPURL "ldaps://ldap.domain.com/ou=users,dc=domain,dc=ccom?uid?sub?(&(uniqueidentifier=*)(objectclass=eperson))"
        AuthLDAPGroupAttribute ibm-allmembers
        require ldap-group cn=mis,ou=web,ou=Groups,dc=domain,dc=com
        Satisfy Any

Note: the group terms are specific to the IBM Tivoli LDAP server.

4) hg integration with Hudson

This one seemed simple enough, given that there is a mercurial plugin for hudson. It was simple enough to install, but took a bit of effort to get going. I had to go into the hudson configuration, and define a mercurial "instance" pointing to a wrapper that set the PYTHONPATH environment variable, then delegated the argument to mercurial itself. Again, I think this is due to the /usr/local/lib64 path the mercurial installer chose. Maybe this could be done more cleanly, but it's working now.

Another hiccup with the hudson configuration, was that there was no place to put a username and password, as one did with the svn/hudson config. I worked around this by adding the IP of my hudson server to the "allow from" section of my apache config file. Thus hudson could pull from my hg repos without authenticating.

A few hurdles with this one, but nothing severe.

Update (in answer to a comment):
My hg warpper looks like:

# cat /usr/local/bin/hg_pythonpath_wrapper
#!/bin/sh
export PYTHONPATH=/usr/local/lib64/python2.4/site-packages
/usr/local/bin/hg "$@"

To get hudson to use this wrapper, goto: Manage Hudson -> Configure System Scroll down to the mercurial section, click the "Add Mercurial" plugin, and point the executable to the above wrapper.

5) The maven release plugin

I use the maven release plugin to perform my releases. I initially tried to get maven to push/pull from the "central" hg repository I had setup, but ran into similar authentication issues as I did with hudson. I read some advice on using the maven release plugin with mercurial, and realized I was still thinking in terms of subversion. Of course it makes more sense to do the release against a local hg repo, and only push the change-sets if the release worked. Oh I love mercurial! And that's it. One day later, and I've converted our multi-module subversion repository into several mercurial directories served by apache with LDAP authentication. Our hudson continuous integration polls the "primary" mercurial repository, and maven tags releases against my local repo. I was told correctly, one you ditch subversion and go with mercurial, you'll never go back.

Glassfish V2 and V3 on the same host, behind mod_jk

2010-01-20T08:11:00.000-08:00

I've jumped on the JavaEE 6 bandwagon, with one application already in production. The developer productivity improvements in JavaEE6/Glassfish V3 are tremendous. The only downside is that I still have some JavaEE 5 applications in production. The JavaEE 5 apps can't migrate to JavaEE 6 until Icefaces supports JSF 1.2.

One workaround to this is to bundle the JSF 1.2 implementation with your application, then configure the classloader using the sun-web.xml file to load this bundled JSF library instead of the container's JSF 2.0 library. This however only works with a standalone WAR file; when the WAR is bundled in an EAR, and references other EJB-JAR's, this trick isn't possible. Yet I still wanted to move new application development to JavaEE 6.

My solution was to run both Glassfish V2 and Glassfish V3 on the same box, with mod_jk forwarding requests to the appropriate container. In this way I am able to keep my existing JavaEE 5 / Icefaces applications running, and deploy new applications to the JavaEE 6 environment.

The first step was to get GF v2, and GF v3 running on the same machine. I have GF v2 running on the standard ports, and I incremented each port by 1 for GF v3. It looks like:

	GF v2 Port	GF v3 Port
HTTP	8080	8081
HTTPS	8181	8182
HTTP - ADMIN	4848	4849
IIOP	3700	3701
IIOP SSL	3820	3821
IIOP SSL-MUTUALAUTH	3920	3921
JMX	8686	8687
JMS	7676	7677

Next, we had to get mod_jk installed and working. The glassfish support team (yes, I pay for support!) pointed me to the following resources:

V2 instructions - http://weblogs.java.net/blog/2006/03/17/running-glassfish-apache-httpd
V3 instructions - http://weblogs.java.net/blog/2009/06/24/running-glassfish-v3-apache-httpd

These were a great starting point, from which I ended up with the solution.

mod_jk.conf:

#mod_jk/1.2.28
LoadModule jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/conf.d/worker.properties
# Where to put jk logs
JkLogFile /var/log/httpd/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel info
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories +DisableReuse
# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"

# Should mod_jk send SSL information (default is On)
JkExtractSSL On
# What is the indicator for SSL (default is HTTPS)
JkHTTPSIndicator HTTPS
# What is the indicator for SSL session (default is SSL_SESSION_ID)
JkSESSIONIndicator SSL_SESSION_ID
# What is the indicator for client SSL cipher suit (default is SSL_CIPHER)
JkCIPHERIndicator SSL_CIPHER
# What is the indicator for the client SSL certificated? (default is SSL_CLIENT_CERT)
JkCERTSIndicator SSL_CLIENT_CERT

# Set the following if you want all vhosts to inherhit JkMounts from global
JkMountCopy All

# Send requests to GlassFish
JkMount /javaee6app* worker1
JkMount /javaee6app/* worker1

JkMount /javaee6app* worker2
JkMount /javaee6app/* worker2

# Send all glassfish-test requests to GlassFish
JkMount /glassfish-test/* worker1

JkShmFile /var/log/httpd/jk-runtime-status

And worker.properties:

## Define 1 real worker using ajp13
worker.list=worker1,worker2
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost.localdomain
worker.worker1.port=8009
#Only used for a member worker of a load balancer. 
#worker.worker1.lbfactor=50
#Do not use cachesize with values higher then 1 on Apache 2.x prefork
#worker.worker1.cachesize=10
#connection_pool_size replace cachesize as of v1.2.16
worker.worker1.connection_pool_size=1
worker.worker1.connection_pool_timeout=0
worker.worker1.socket_keepalive=1
#Socket timeout in seconds
worker.worker1.socket_timeout=60

worker.worker2.type=ajp13
worker.worker2.host=localhost.localdomain
worker.worker2.port=8010
#Only used for a member worker of a load balancer. 
#worker.worker2.lbfactor=50
#Do not use cachesize with values higher then 1 on Apache 2.x prefork
#worker.worker2.cachesize=10
#connection_pool_size replace cachesize as of v1.2.16
worker.worker2.connection_pool_size=1
worker.worker2.connection_pool_timeout=0
worker.worker2.socket_keepalive=1
#Socket timeout in seconds
worker.worker2.socket_timeout=60

These are not the worker.properties as prescribed in the above links. After implementing the initial solution, I got reports from the wild of users mysteriously losing sessions. After much reading about mod_jk, I think I narrowed down the problem to a cachesize/connection_pool_size > 1 in conjunction with the prefork mpm apache module. Apparently this is a no-no.

So with these settings in place, I am able to develop new apps in JavaEE 6, while still running my older JavaEE 5 apps, on the same box. Looking forward to Icefaces 2.0 though, so I can drop this needless complexity!

In the beginning...

2009-11-14T00:11:00.000-08:00

Ok, this is my blog. I'm not sure how I will use it, for the most part it will just be a place where I can organize my thoughts and ideas about Java development. Maybe it will be useful for others, but probably not!