Groovy+Mojarra

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:

1. 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)
2. 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.
   

   1. 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.
      
   2. 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.

3. 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.

Like this post? | | | |

Posted at 02:09PM Apr 17, 2008 by rlubke in Personal
Tags: groovy jsf mojarra