JSF and automatic reload of Facelets files

Question

I had some problems with hot-reloading Facelets files using JRebel, Spring, JSF Mojarra 2.0.3 and WebLogic 10.3.

JRebel reloads regular Java classes and js/css files under /WebContent successfully, but not JSF's .xhtml files. A full republish was necessary to get xhtml files updated on the server.

By trial and error I finally got it to work by adding some facelets parameters to web.xml and creating a custom ResourceResolver as described in this blog post.

However, I wonder WHY this works, and more specifically:

• Why is a custom ResourceResolver needed?
• Isn't JRebel supposed to handle this by monitoring /WebContent where the xhtml files reside?
• I'm guessing it has something to do with Facelets/JSF compiling xhtml to servlets(?) via FacesServlet which JRebel is unable to detect?

Decreasing

Answer 1

JRebel handles /WebContent folder changes.

The problem is that Facelets do caching and do not reread changed files. To force reload specify one of the following parameters in web.xml.

JSF 2+ (Facelets 2+):

<!-- Set the project stage to "Development", "UnitTest", "SystemTest", or "Production". -->
<!-- An optional parameter that makes troubleshooting development stage errors much easier. -->
<!-- You should remove this context parameter before deploying to production or override via Server's JNDI config! -->
<context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
</context-param>

This will automatically set the "Facelets refresh period" configuration to 0, hereby effectively disabling the Facelets cache.

Or, if you don't want to change the project stage, then

<!-- Time in seconds that Facelets should be checked for changes since last request. A value of -1 disables auto-refresh. -->
<!-- You should remove this context parameter before deploying to production or use PROJECT_STAGE instead! -->
<context-param>
    <param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
    <param-value>0</param-value>
</context-param>

For Faces 4.x the javax. prefix should be jakarta. instead, like so jakarta.faces.PROJECT_STAGE and jakarta.faces.FACELETS_REFRESH_PERIOD.

---

For JSF 1.2 (Facelets 1.x) the equivalent parameters are:

<context-param>
    <param-name>facelets.DEVELOPMENT</param-name>
    <param-value>true</param-value>
</context-param>

<context-param>
    <param-name>facelets.REFRESH_PERIOD</param-name>
    <param-value>0</param-value>
</context-param>

More on JSF context params: http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html/jsf.reference.html#standard.config.params

That custom resource resolver is not needed in your case. That resource resolver is just a tricky way to get xhtml files from custom file system folder. In your case JRebel does that (and even more).

Rotatory

I believe that JRebel already implicitly does that. At least, here it does. Note that your context params are Facelets 1.x specific and that OP is using Facelets 2.x. – Hyden

@Balusc Thanks for reply, answer updated to be Facelets 2.x specific. – Rotatory

Setting javax.faces.FACELETS_REFRESH_PERIOD to 0 and javax.faces.PROJECT_STAGE to Development does not seem to trigger updated templates with JRebel on JSF 2.0.4 and WebLogic 10.3. – Sheol

@Sheol OP has noted that 'finally got it to work by adding some facelets parameters to web.xml and creating a custom ResourceResolver '. I don't know whether it works for him without custom resource resolver. – Rotatory

Gotta love stack overflow. javax.faces.FACELETS_REFRESH_PERIOD worked perfectly for me. JBoss 4, JSF2. – Radiogram

Our team uses Glassfish 3/IceFaces and we had FACELETS_REFRESH_PERIOD set to -1 for quite a while. Setting it to 0 enabled hot-reloading XHTML. – Discommode

this change is a must in order to use jsf with jrebel – Botfly

Answer 2

Here's how I fixed this for me:

1. Verify that facelets plugin is enabled in your JRebel settings &
2. Verify that you're using Project Stage Development in your web.xml

Gadgetry