Groovy+Mojarra

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.

Comments:

Nice, Ryan! This is much cooler than what I was able to achieve by just throwing the JSF managed beans into Spring and using Spring's Groovy (and ruby) support...

Posted by Kito d. Mann on April 18, 2008 at 03:57 AM PDT #

It's nice to have something like this in the RI.

Storing the scripts separately in /WEB-INF/groovy and having to suffix them with .groovy seems extraneous. It might be better to have them live in /WEB-INF/classes with the rest of the classes, and avoid the suffix.

That way, when you're rolling to production, you can just compile your groovy objects to .class files, remove the GroovySupportFilter from your web.xml, and be done.

You'd have to make your GroovyHelper and supporting classes a bit smarter, I suppose. Any reason not to do this?

Posted by Daniel McSorley on April 18, 2008 at 06:26 AM PDT #

Wonderful stuff. Thanks for the post. Once the Netbeans Groovy Plugin is mature, Netbeans + Groovy + JSF + Glassfish should be a powerful combination.

Posted by Markus Jais on April 18, 2008 at 05:29 PM PDT #

Just putting the nightly build and groovy in the sample project did not work for me. I had to use the glassfish updater and put groovy-all.1.5.5.jar in the glassfish lib directory. Is this to be expected?

Posted by kv on April 18, 2008 at 09:50 PM PDT #

Thanks dude! Now we have Groovy as second choice for JSF development! Please continue this amazing work!

Posted by Rogério Araújo on April 20, 2008 at 01:06 AM PDT #

Thanks!! Groovy will facilitate the JSF applications development!

Posted by Rafael Ponte on April 20, 2008 at 01:50 AM PDT #

This is quite nice! Good job! In combination with something like gracelets (http://www.seamframework.org/Community/GroovyFaceletsGracelets) that could become the killer JSF combination boosting productivity. Congrats.

Posted by Guillaume Laforge on April 21, 2008 at 12:37 AM PDT #

@kv: yes, you'll have to use the glassfish updater to update the JSF libraries within Glassfish. As to why the setup fails when groovy-all is in WEB-INF, well, we'll investigate and get back with you.

@Daniel: Thanks for the feedback. The code as it exists now can certainly be changed. To answer your questions, having the extension present allows us to know when certain proxies are needed. I'll be looking into possible alternatives to detect this case so that the extension isn't required.

Posted by Ryan Lubke on April 21, 2008 at 03:40 AM PDT #

@kv: After a quick look, yes, groovy-all-1.5.5.jar will need to be installed in GF_HOME/lib. More specifically, the groovy classes will need to be available to the same classloader that loaded the JSF classes, or be present in the parent classloader.

Posted by guest on April 21, 2008 at 05:02 AM PDT #

@Daniel: The groovy support has been updated so that inclusion of the .groovy extension isn't necessary. For now we're still requiring the /WEB-INF/groovy to store scritps that will be interpreted at runtime.

Posted by Ryan Lubke on April 29, 2008 at 11:10 AM PDT #

Nice Ryan!
How can i use this with maven?

Posted by Andreas on May 05, 2008 at 07:34 PM PDT #

> When using this feature, I highly recommend the use of Facelets

I am praying that you get rid of JSP in JSF 2.0. For the maintainer of the JSF RI to be recommending the use of Facelets is a sure sign that JSP is just wrong for JSF and it is very much hurting its adoption. Kill JSP, please!!! I freakin' hate it!

Posted by Dan Allen on May 12, 2008 at 05:54 AM PDT #

Ryan,

I'd really like to see the "groovy" directory name configurable (using "groovy" as the default is fine, though). This would make it easier to use the directory as a standard Java directory, too.

Posted by Kito d. Mann on May 21, 2008 at 03:55 AM PDT #

Dude, I don't know much about you but I saw you not too long ago and I am extremely interested in what you have to say. Perhaps you may be able to help me?

Posted by S. Louise on June 30, 2008 at 03:01 PM PDT #

Hello, I am trying your example but unlucky,
glassfish cmplain about com.sun.faces.scripting.GroovySupportFilter
"Cannot load com.sun.faces.scripting.GroovySupportFilter reason : com.sun.faces.scripting.GroovySupportFilter
java.lang.ClassNotFoundException: com.sun.faces.scripting.GroovySupportFilter
"
I have put the in web-inf/lib groovy-all-1.5.5.jar and added facelets frameqork, but it does not help, can anyone give me fully worked
JSF/FACELETS/GROOVY example under netbeans 6.1?

Posted by Armen on September 17, 2008 at 08:26 PM PDT #

Dear Ryan,

I'm using Mojarra with Groovy on Tomcat 6.0 and it works great except that I cannot use @Resource annotation inside my groovy backing beans for injection. Do you have any idea of what I should check?

Posted by Amir on September 20, 2008 at 03:44 PM PDT #

[Trackback] Eine Scripting sprache wie Groovy bei der Entwickling von JSF Webapplikationen  zu verwenden klingt ziemlich interessant. Scheinbar ist es damit möglich, ActionListener und Beans quasi zur Laufzeit zu ändern ohne die Applikation neu verteilen/neu st...

Posted by Core-Dump on January 28, 2009 at 09:33 PM PST #

Interesting!

Posted by Sabau Ioana on February 17, 2009 at 12:32 AM PST #

Post a Comment:
Comments are closed for this entry.
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