Watching the Sun set....

Thursday Jan 21, 2010

I'm very grateful for the past nine years Sun.  Looking forward to see what the future holds...

Glassfish V3+Mojarra 2.0.2

Thursday Dec 10, 2009

There's a lot of buzz today around the release of GlassFish V3.  

Instead of duplicating content, I would recommend reading this blog entry about the release posted to The Aquarium.

I'd like to point out that the Mojarra project team has also pushed the Mojarra 2.0.2 patch release out today as well.  This patch release is included with V3 already, so no need to upgrade.  If, by chance, you're using GlassFish V2 with Mojarra 2.0, follow the upgrade instructions outlined in the release notes.

Mojarra 2.0.0 is available!

Monday Oct 19, 2009

Mojarra 2.0.0 is now available!

There are several ways to obtain the release. 

• GlassFish V3 promoted build 69 (out later this week)
• Download directly from https://javaserverfaces.dev.java.net
• Download using Maven2 using information provided here

Please review the release notes as there are important details there pertaining to differences between the implementation and the specification as well as a basic migration guide from 1.2 to 2.0 (note that this is a live document, so we'll be making additions - check back regularly).

The JSF 2.0 tutorial from our Sun documentation team should be available in the coming weeks.  As soon as it is, we'll send out a notification.  Until then, here are some nice resources for JSF 2.0:

• Andy Schwartz' blog entry - What's New in JSF 2
• Ed Burns' blog - http://www.java.net/blogs/edburns/
• Jim Driscoll's blog - http://www.java.net/blogs/driscoll
• JSF 2.0 EG blog - http://blogs.jsfcentral.com/jsf2group/

On the tools+JSF 2.0 front, NetBeans is well underway with the JSF 2.0 support.  I'd recommend grabbing the NetBeans development build and try it out!  Ed noted the other day that you could highlight a section of markup in a Facelet template and extract it into a composite component.  Slick!  The JetBrains guys have been busy as well.  Check out their blog on JSF 2.0 support within Maia.

I'd like to personally thank all of our external contributors who have been committing code to the repository directly or submitting patches to help improve our quality (these are in no particular order - my apologies if I've missed anyone):

• Guy Veraghtert
• Imre Oßwald
• Ted Goddard
  
• Mark Collette
  
• Dan Allen
  
• Alexandr Smirnov
  
• Martin Marinschek
• Michael Kurz
• Andy Schwartz
  

I'd also like to thank our top three issue reporters for taking the time to log issues (again, in no particular order)

• Frank Hofmann
• Guy Veraghtert
• Juergen Zimmerman

Also, thanks to Ed Burns, Roger Kitain, Jim Driscoll, and Doug Donahue for putting up with me for the past two years while we worked on this project :)

Finally, if you'd like to discuss JSF 2.0 with other users, I'd recommend the following:

• GlassFish Webtier Forums
  
• ##jsf IRC channel on freenode.net

The GlassFish Webtier forums are monitored by the Mojarra developers.   The IRC channel, also, is frequented by the Mojarra developers, as well as folks from Exadel, MyFaces, and consumers of JSF as a technology.  It's a great way to interact with the community.

I'm excited that we've reached this stage and am looking forward to hearing/reading about people's experiences with JSF 2.0!

JSF 2.0 - What's New

Friday Jul 31, 2009

Andy Schwartz, one of the JSF EG members, has written an excellent blog [1] on what's new in JSF 2.0.
Definitely worth a read!

[1] http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/

Mojarra 1.2_13 has been released.

Monday Jul 06, 2009

Just a quick note to let folks know that 1.2_13 has been released.   Please see the announcement for details.

JSF Configuration Resource Ordering

Wednesday May 27, 2009

A common issue in JSF 1.1/1.2 was the inability to control the order in which faces-config.xml files were parsed when said files were included in a JAR file.  Why does ordering matter?  Consider the decoration of entities such as ViewHandler or Application.  If your application contains more than two ViewHandlers, you may wish to have the ViewHandler delegation chain configured in a certain order.
The same holds true for PhaseListeners.  A developer may wish to have PhaseListenerB execute before PhaseListenerA.

A stop-gap measure was implemented by Mojarra (MyFaces does the same I believe) where the ordering of META-INF/faces-config.xml documents was determined by the natural sort order of the JAR name that contained the file.  While this worked, it wasn't a perfect solution as you were then forced to rename the JAR files to achieve the desired result.

JSF 2.0 solves this by requiring implementations to support partial ordering of the configuration resources via the ordering element.
The ordering element offers a way for a single document to state it wishes to be ordered before or after a specific document, or a group
of documents.  Documents can be identified by the top-level name element.  It's imporant to note that there are two documents in configuration processing that are always processed in a specific order and as such the ordering element has no impact.  The implementation default configuration resource is always processed first and the WEB-INF/faces-config.xml (if present) is always processed last.

Given the above, let's start with an example straigh from the specification:

A.faces-config.xml:

<faces-config>
    <name>A</name>
    <ordering>
        <after>
            <name>B</name>
        </after>
    </ordering>
    <application>
        <view-handler>com.a.ViewHandlerImpl</view-handler>
    </application>
    <lifecycle>
        <phase-listener>com.a.PhaseListenerImpl</phase-listener>
    </lifecycle>
</faces-config>

B.faces-config.xml:

<faces-config>
    <name>B</name>
    <application>
        <view-handler>com.b.ViewHandlerImpl</view-handler>
    </application>
    <lifecycle>
        <phase-listener>com.b.PhaseListenerImpl</phase-listener>
    </lifecycle>
</faces-config>

C.faces-config.xml:

<faces-config>
    <name>C</name>
    <ordering>
        <before>
            <others />
        </before>
    </ordering>
    <application>
        <view-handler>com.c.ViewHandlerImpl</view-handler>
    </application>
    <lifecycle>
        <phase-listener>com.c.PhaseListenerImpl</phase-listener>
    </lifecycle>
</faces-config>

D.faces-config.xml:

<faces-config>
    <name>D</name>
    <application>
        <view-handler>com.my.ViewHandlerImpl</view-handler>
    </application>
    <lifecycle>
        <phase-listener>com.my.PhaseListenerImpl</phase-listener>
    </lifecycle>
</faces-config>

Looking over the four documents, we see that:

• Document A is after document B
• Document B has no ordering requirements
• Document C is uses the others element to say it should be ordered
  before all the other documents that are being sorted
• Document D has no ordering requirements
  

The resulting parse order may be:

1. Implementation specific configuration resource
2. Document C
3. Document B
4. Document A
5. WEB-INF/faces-config.xml (if present)
   

Here's a couple other examples to illustrate an important point about the ordering.  When documents state they wish to be before or after another document, it may not necessarily be the case that the documents are ordered right next to each other.  I think the following examples will clarify what I mean:

Document A - <after><others/><name>C</name></after>
Document B - <before><others/></before>
Document C - <after><others/></after>
Document D - no ordering
Document E - no ordering
Document F - <before><others/><name>B</name></before>

The resulting parser order could be [F, B, D, E, C, A], but [F, B, E, D, C, A] would also be accurate.

Here's another:

Document <no id> - <after><others/></after><before><name>C</name></before>
Document B - <before><others/></before>
Document C - no ordering
Document D - <after><others/></after>
Document E - <before><others/></before>
Document F - no ordering

Possible parsing orders are:

• B,E,F,<no id>,C,D
• E,B,F,<no id>,C,D
• B,E,F,C,<no id>,D
• E,B,F,C,<no id>,D

An important note on that last example - if a document has ordering requirements, but no name, then the ordering requirements will be ignored.

Now, there are most likely going to be cases where the resulting partial parsing order doesn't quite fit with what an application needs.
In that case, the developer can fallback to another new element called absolute-ordering.  This element is only valid within the WEB-INF/faces-config.xml and will be ignored in all other cases.  The use of this element allows the developer complete control over the order that faces-config documents will be processed.

Here's a simple example:

<faces-config>
    <absolute-ordering>
        <name>C</name>
        <name>A</name>
    </absolute-ordering>
    .
    .
    .
</faces-config>

In this case, the parsing order would be:

• Implementation specific configuration resource
• Document C
• Document A
• WEB-INF/faces-config.xml

It's pretty simple, however, developers should be aware that any documents that aren't explicitly referenced within the absolute-ordering element will not be processed.  Though it is possible to include those documents without having to enumerate them all individually.

Consider:

<faces-config>
    <absolute-ordering>
        <name>C</name>
        <others />
        <name>A</name>
    </absolute-ordering>
    .
    .
    .
</faces-config>

In this example, assuming we started with documents [A, B, C, D], then the resulting parse order may look like:

• Implementation specific configuration resource
• Document C
• Document B
  
• Document D
• Document A
• WEB-INF/faces-config.xml

Note that B/D could be interchanged.  The others element may appear any where within the absolute-ordering element, but it may only do so once.