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

By user12615560 on Feb 15, 2008

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.