Thursday Apr 17, 2008
Starting with tonight's nightly build of Mojarra 1.2_09,
developers can opt to use Groovy to enable rapid prototyping for their
JSF applications.
Why Groovy?
Several reasons.
First and foremost was the learning curve that java developers
would face when using Groovy. Since Groovy scripts can be written in
either standard java syntax or using Groovy's syntax, it's one less thing for
developers to learn when trying to write their applications. Just use
standard Java syntax in the .groovy file and get on with your work.
This also means that once you're done prototyping in Groovy, you can copy
the source to a .java file and include it in your standard build process so
that your code can run on any JSF implementation. Another is
annotation support. Groovy-based managed beans can use resource injection per the JSF 1.2 specification. Finally, from an
integrator's standpoint, I could call the Groovy runtime and
get a regular Class made this integration easy to do (i.e. not a lot of
changes were needed to the core).
How to enable Groovy
support
Enabling Groovy support is fairly straight forward.
Just follow these steps:
- Download Groovy 1.5.5 and include the groovy-all-1.5.5.jar with your web
application (or copy it to your application server's lib directory)
- Add the following to your web.xml
<!-- Enable Groovy Support --> <context-param> <param-name>com.sun.faces.developmentMode</param-name> <param-value>true</param-value> </context-param> . . . <filter> <filter-name>GroovyFilter</filter-name> <filter-class>com.sun.faces.scripting.GroovySupportFilter</filter-class> </filter> <filter-mapping> <filter-name>GroovyFilter</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher> <dispatcher>ERROR</dispatcher> </filter-mapping>
|
The init parameter com.sun.faces.developmentMode serves two
purposes.
- When enabled, any changes to any faces-config.xml under
WEB-INF
will cause the faces application to be re-loaded
without having to
redeploy. This is handy as you add
new managed beans or other
artifacts to your
application.
- For certain JSF artifacts, specifically those that can be
considered
stateless application singletons (think Renderer
or PhaseListener),
Mojarra will wrap groovy based versions
of these classes with a proxy
so that changes to a Render or
PhaseListener are picked up at runtime
without a reploy
step.
One might wonder what the filter is for. This filter simply
ensures the
the context classloader is properly setup.
Unfortunately it is needed to
an issue in GlassFish and Tomcat
where the context classloader is reset
on a forward, somthing
that is a common task in web applications.
Create a directory under WEB-INF called groovy.
These are where your
groovy scripts will be placed. You can
use the the typical package scheme
as you would with typical java
source files. When referencing Groovy scripts
within the
faces-config.xml, make sure you include the .groovy extension.
Exmaples:
<managed-bean-class>sample.SimpleBean.groovy</managed-bean-class>
UPDATED APR 29, 2008 : Including the .groovy extension is no longer necessary
What artifacts can be scripted with Groovy
The
support we've added allows you to use Groovy for all JSF artifacts.
Artifact
|
Dynamic Reloaded
|
Managed Beans
|
Yes (*)
|
Renderer
|
Yes
|
PhaseListener
|
Yes
|
ActionListener (application level)
|
Yes
|
Renderer
|
Yes
|
ELResolver
|
Yes
|
Component
|
Yes
|
Converter
|
Yes
|
Validator
|
Yes
|
ApplicationFactory
|
Yes(**)
|
FacesContextFactory
|
Yes(**)
|
LifecycleFactory
|
Yes(**)
|
* If a reload of the faces-config.xml was not triggered, session scoped or
application scoped beans won't show changes until they have been removed
from scope. That said, if a faces-config reload occurs, all known sessions
will be invalidated and all application scoped beans will be removed.
** While these artifacts can be scripted they tend to hold state so you'll need
to trigger a faces-config reload (a simple touch of the faces-config.xml will do)
to view changes. Still no recompile or redeploy necessary.
When using this feature, I highly recommend the use of Facelets for two major reasons. The
first being there are no tags or tlds that need to be maintained. This
is important since there is no dynamic reloading of JSP tag handlers or TLDs
at the moment. The second is that the facelets taglib files will be
reloaded when a faces-config reload occurs, so again no redeployment!
For those who use NetBeans, this feature really shines. Within NetBeans one is able to run/deploy the project and then make changes to your
groovy, faces-config.xml, facelets taglib and xhtml files, save then and
reload within the browser and see the changes (again - no redeploy)!
I found this particularly handy when writing groovy-based renderers and
components. Feel free to download this sample
Facelets-based NetBeans project that is setup for groovy development
(includes a simple Groovy bean and all of the configuration so you don't
have to mess with it). Note that you still need to provide
Facelets, Groovy, and the Mojarra nightly build. I should point out
this blog which references a
Groovy plugin for NetBeans. I've been using it while testing the
functionality and while it's missing some features, it's a nice alternative
to treating Groovy scripts as plain text.
All of this having been
said, this support is still new, so I'm sure there are still some snags
hiding somewhere in the code. If you find any, please log an issue
detailing the problem you have. We'll be sure to get the bug fixed as
soon as possible. Likewise, any ideas on how to improve the
feature/end-user experience, let us know on the Mojarra user or dev
mailing lists. We'd love to hear from you.
Friday Apr 04, 2008
Today I was asked if Trinidad required MyFaces to work as it's a MyFaces project.
There seems to be some misconception about component sets and JSF.
The key here is that component sets, assuming they code to the spec, can run
on *any* JSF compliant runtime. This means that Trinidad should run on either
MyFaces or Mojarra.
I've worked on and off with a couple of the Trinidad developers over the years
where I've received feedback regarding issues running Trinidad on Mojarra (which
we've always tried to address in a timely fashion). So I know by word of mouth
that it works, but today I decided to try it out for myself.
I downloaded the Trinidad 1.2.7 demo (for JSF 1.2) and deployed to GlassFish V2UR1.
After doing so I was able to run the Survey demo and browse through the component
guide without issue.
Some basic information about Trinidad:
- Partial-page rendering support for all Trinidad components (read Ajax)
- Client-side validation support
- Dialog framework
- pageFlowScope for inter-page communication
The component set is quite extensive. The components range from bread crumbs,
to color choosers, accordion panels, progress indicators, and many others you'd
expect to find in a robust component set. I'd recommend going through the
demo to view each of them in action.
Saturday Feb 16, 2008
This is the third blog in the JSF 2.0 New Feature Preview Series.
The previous entry covered packaging of resources. Now we'll cover the APIs that back
this feature. 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.
Two new API classes are available for Resource handling:
- javax.faces.application.ResourceHandler [1]
- javax.faces.application.Resource [2]
The Resource class is pretty straight forward. This class is basically a representation
of an actual resource such as an image or style sheet. It also provides methods
to help the ResourceHandler serve the underlying resource.
The ResourceHandler class is responsible for both creating Resource instances as well
as serving said resources to the user-agent.
So how does a developer leverage these classes? Well, in general, a developer
will obtain the ResourceHandler (FacesContext.getApplication().getResourceHandler())
and create one or more Resource instances (ResourceHandler.createResource()).
Then the Resource can be encoded (Resource.getRequestPath()) that will generate
a special URI for serving it.
For example, let's say a Renderer is writing out an HTML img tag. The result
of calling Resource.getRequestPath() will be the value of the img tag's src attribute, and
when rendered to the browser would look something like:
<img src="<context-root>/javax.faces.resource/<resource-name> +
[?ln=<library-name>][&loc=<locale-prefix>][&v=<version>]
Let's break this down. As per the previous blog regarding packaging, there are several
bits of meta-data associated with a Resource. These are its library name, locale, and
version (all optional). If a Resource has any of these, they will be encoded in the URI.
If any of the values change, such as the locale prefix or a version increment, the change
will be present in the URI and because the URI differs the user-agent will request the
new resource automatically.
One might be wondering how the resources are served. Past attempts as resolving this
issue have used a PhaseListener, or a Filter, but the neither are used in this case.
The solution, to avoid having to specify additional artifacts in the faces-config or web.xml,
is to have the FacesServlet leverage the ResourceHandler directly. Specifically, the
FacesServlet will, on each request, ask the ResourceHandler (by invoking
ResourceHandler.isResourceRequest()), if the current request is a Resource Request
(i.e. the request URI contains the identifier /javax.faces.resource), and if it is determined
to be a Resource Request, the FacesServlet will call handleResourceRequest() on the
ResourceHandler to serve the resource. If the request is not a Resource Request, the
standard JSF lifecycle processing will occur.
It should be noted that when serving resources, the ResourceHandler will ask the Resource
instance if the user-agent requires updating, so that if the resource hasn't changed, a 304
can simply be returned to reduce the load of the network.
Also, the behavior of Mojarra's implementation of ResourceHandler will differ depending
on the current value for ProjectStage. If the current stage is Development, any request
to the ResourceHandler to create a Resource will result in the system computing the
paths and searching for the resource. Since this process is expensive, Mojarra will, when
the ProjectStage is Production, cache the resource meta-data to lessen the load on the
system. By default changes will be checked for every five minutes and if changes are
found, the cache is dumped so that it will be rebuilt with the new changes that are
present. I wanted to point out that when developing a project and you want to see
any resource additions picked up right away make sure you've set the ProjectStage for
Development.
Finally, like other artifacts within JSF, if the default implementation doesn't suit your needs,
you can completely replace or decorate the implementation with functionality that meets
your requirements.
[1] Raw source for javax.faces.application.ResourceHandler
[2] Raw source for javax.faces.application.Resource
Friday 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:
- /resources this location represents resources in the webapp itself
and if present, must be in the root of the web application
- /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, etc., and if used, the resource handling mechansim must use the lastest
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.
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.
Thursday Feb 14, 2008
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.
Friday Feb 08, 2008
When a developer first starts working with JSF, the common question
is what components libraries are available and what do they offer. Answering this question usually requires some digging.
The site jsfmatrix.net <http://www.jsfmatrix.net>,
however, tries to provide some relief. This site provides a nice
comparison matrix of some of the more popular JSF component libraries
that are available. There are a few inaccuracies (for example,
Woodstock does include support for Facelets), but the author of the
site seems to perform updates as time permits (see the comments
section).
Of the component libraries listed, I can say that Woodstock, ADF,
Trinidad, Tomahawk, ICEFaces, RichFaces, Blueprints all work with
Mojarra <https://javaserverfaces.dev.java.net> (and by proxy GlassFish <https://glassfish.dev.java.net>).
There are two other component libraries that I also know work with Mojarra. Manor 'n Rock <http://www.manorrock.com/products/jsf/> and Mojarra Scales <https://scales.dev.java.net>.
Manor 'n Rock has several useful components like Captcha, credit
card, electronic check, or ISBN. All of the components have live
demos, which, incidentally, are running on GlassFish.
Mojarra Scales is a subproject of Mojarra run by Jason Lee <http://blogs.steeplesoft.com>. This component library exposes the YUI Javascript widgets as JSF components.
Nice, Ryan! This is much cooler than what I was ab...
...
Wonderful stuff. Thanks for the post. Once the Net...
Just putting the nightly build and groovy in the s...
Thanks dude! Now we have Groovy as second choice f...
Thanks!! Groovy will facilitate the JSF applicatio...
This is quite nice! Good job! In combination ...