Monday Oct 19, 2009

Mojarra 2.0.0 is available!

Mojarra 2.0.0 is now available!

There are several ways to obtain the release. 

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:

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:

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!

Friday Feb 15, 2008

JSF 2.0 New Feature Preview Series (Part 2.1): Resources

This is the second blog in the JSF 2.0 New Feature Preview Series. 
The previous entry covered ProjectStage, now we'll cover Resources.
Keep in mind that none of the features described are final, and may change,
but this is a good opportunity to show the features as they exist now and illicit feedback.

The term Resources is pretty vague, so let's clarify that first.  Resources are any
artifacts that a component may need in order to be rendered properly to
a user-agent.  So think images, CSS, or JavaScript files. 

Previous versions of JSF had no facility for serving resources, so component
libraries either had to cook up their own mechanism for serving resources
or use something like Weblets so that these resources could be packaged
with their component library.

JSF 2.0 will have support for this functionality out of the box which should
make life easier for custom component developers.

Packaging


The default implementation will look for resources in two locations
and in the following order:

  1. /resources  this location represents resources in the webapp itself
    and if present, must be in the root of the web application
  2. /META-INF/resources this location represents resources on the
    classpath

First question that may come to mind is why care about resources in the
docroot of the web application?  Don't worry, that will be touched on soon.

The spec further supplies some options for how to structure content under
these resources directories.  This specification looks like this:

  • [localePrefix/][libraryName/][libraryVersion/]resourceName[/resourceVersion]
    items in [] are optional

Let's break these elements down starting with localePrefix.  This allows the developer
to associate a resource with a particular locale identifiter.  If a developer wishes to
leverage this feature, they must add a key/value pair like:
  • javax.faces.resource.localePrefix=<localePrefix>

The value of localePrefix must match the localePrefix within the resources directory.

Next in the path is libraryName.  This is a logical identifier that may be used to represent
a grouping of resources.  This library may be versioned as indicated by libraryVersion.
Finally we we have resourceName.  This is the name of the physical resource (i.e. mast.jpg
or corp.css or js/ajax.js), which can also be versioned.  

Let's take a closer look at versioning.  Version strings are pretty open ended.  They may be 1_1,  1_1_1, 1_1_2_11 (NOTE the _ for the version delimiter), etc., and if used, the resource handling mechanism must use the latest version available (be it library or resource).  This allows you to update resources at runtime without having to redeploy the application.  

The ability to update resources at runtime touches back on looking for resources within
the docroot of the web application.  Consider the following scenario.  An application
uses a component library with resources included within the JAR, for argument's sake,
let's say that the resource path is /META-INF/resources/compLib/script/compScript.js
A bug is found in this .js file and no new version of the component library is available. 
The bug can be fixed locally and placed in /resources/compLib/1.1/script/compScript.js
while the app is live and the new version will be sent to the client.

The last item I wanted to mention with respect to resource (not library) versioning as,
at first blush, it's a bit strange.  The name of the resource is actually the directory,
and the version is the resource content itself.   As an example:  META-INF/resources/compLib/compScript.js/1_1
or META-INF/resources/compLib/compScript.js/1_1.js (developers can optionally include the extension of the file).

The next blog entry will get into the details of the API, but I want to mention it here
as I feel it's important.  From an API persective, the versioning and localePrefix features
are transparent in the API.  This means when leveraging the API, the only info that is
needed is a library name (if any), and the resource name.  The resource system takes
care of the localePrefix and version resolution automatically.

UPDATED Jan 28, 2009 - updated information pertaining to resource/library versions.

Thursday Feb 14, 2008

JSF 2.0 New Feature Preview Series (Part 1): ProjectStage

This will be the first of a small series of blogs covering proposed new features in JSF 2.0.
Keep in mind that none of the features described are final, and may change, but
this is a good opportunity to show the features as they exist now and illicit feedback.

We'll be starting to publish nightly builds of Mojarra 2.0.0 to the project site soon,
but for the time being, you'll have to check out the sources and build the implementation
yourself (luckily, the build is very easy).

So, what is the ProjectStage feature?  In short, the JSF 2.0 EG has given a nod to
Ruby on Rails' RAILS_ENV functionality.

javax.faces.application.ProjectStage provides the following options:

  • Production
  • Development
  • UnitTest
  • SystemTest
  • Extension

These values are configured via a context init-parameter like so:

<context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>   
    <param-value>Development</param-value>
</context-param>
At runtime, you can query the Application object for the configured value
by calling Application.getProjectStage().  The return value will be one of the
defined enums.  If not explicitly configured, then the default will be
ProjectStage.Production.

All of the values outside of Extension are fairly self explanatory, so what is
Extension for?  This allows the developer to leverage custom stages.  So if
a value is specified that doesn't match the existing enumerate values, then
it will be the value for used.  When calling Application.getProjectStage() the
Extension enum value will be returned.  Calling toString() on the return values
at this point will return the value as configured in the web.xml.  This will be
useful for developers building upon the JSF framework to add stages to affect
behavior that is outside the scope of the predefined types.

Overall the idea here is to be able to affect the behavior of JSF based on these
values.  As an example of where this is useful:  consider a simple JSF view that
has several validated input fields and validation fails.  If there is no h:messages
component in the view, the page appears to do nothing.  I can't tell you how
many forum postings I've run across where this type of thing occurs, and the
first response is always 'add h:messages to your view and try again'.  

Here is where ProjectStage comes in:  If the current stage is Development and
no h:messages is present in the view, we'll add one automatically for the user.  
If the stage is Production we'd take no action (assuming the user would have
this all corrected - no need to try to modify the tree).

While this feature may seem relatively minor, I wanted to discuss it first as
it impacts the feature I'll be discussing in my next entry - stay tuned!


UPDATE: 2/19/2008 - JNDI configuration implemented

Per the feedback provided to this blog entry, we've implemented the ability to
configure ProjectStage via JNDI.  Then Application.getProjectStage() is first
invoked, it will first check for a value from JNDI, if not found, it will then check
for  a context init parameter, finally defaulting to ProjectStage.Production if no
configured value is found.  The JNDI name that is currently spec'd is
java:comp/env/jsf/ProjectStage

Additionally, we've added a JNDI ObjectFactory to Mojarra to make it easy for
developers to make a custom global JNDI resource to configure ProjectStage.

Here is an example of how to define this ObjectFactory in GlassFish:


The value of the stage property is what will be returned from the JNDI lookup.

It should be noted that mapping global JNDI resources to component resources
(java:comp/env) is, unfortunately, an implementation specific process.  So,
to continue using GlassFish as an example, you'd need to add a resource-ref
entry to the web.xml:

            <resource-ref>
                <res-ref-name>jsf/ProjectStage</res-ref-name>
                <res-type>java.lang.String</res-type>
            </resource-ref>

Then you need to map the res-ref-name to the global JNDI resource via the
sun-web.xml (also in /WEB-INF/):

             <resource-ref>
                 <res-ref-name>jsf/ProjectStage</res-ref-name>
                 <jndi-name>javax.faces.PROJECT_STAGE</jndi-name>
             </resource-ref>
           

Alternatively, the JNDI configuration could be done by a simple env-entry
in the web.xml, but this doesn't allow you to configure ProjectStage for all
applications without modifying the web.xml.

 

About

user12615560

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today