Faster development of ADF applications – When to simply refresh the browser and when to redeploy the web application

ADF developers frequently are not exactly sure which changes they have applied to the application can be picked up in the running application, without redeploying the application, and which changes absolutely require a redeploy as they can not be added to a running application. Knowing when redeploy is not necessary – and increasing the number of times that a simple save, (compile,) and browser refresh suffices will streamline development enormously. Redeploying the web application usually is a lengthy affair, from 10 seconds to much longer.

There are actually only a few file types whose change cannot be hot-redeployed and require full restart of the application. This primarily concerns XML files that are loaded by the JSF/ADF framework at runtime when the application starts and not reloaded at any later point in time, such as faces-config.xml and the ADFm Page Definition files.

Changes that do NOT need redeploy

• JSPX and JSP
• JSFF (although sometimes it seems that in order to get the change through, a small change (add a space will do) to the consuming JSPX is required)
• CSS
• JavaScript

Note that due to browser caching you sometimes may have to use Force Refresh (CTRL F5 in some browsers) to reload the changed CSS and JavaScript resources.
The ADF Developer’s Guide seems to suggest that some settings are required in the web.xml to make sure the changed JSPX files for example are picked up. For me that does not seem necessary (they are picked up anyway, perhaps due to settings on the Integrated WebLogic Server). For completeness sake:

You can specify the following debugging context parameter: org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION:

By default this parameter is false. If it is set to true, ADF Faces will automatically check the modification date of your JSPs and CSS files, and discard the saved state when the files change.

Performance Tip: When set to true, this parameter adds overhead
that should be avoided when your application is deployed. Set to
false when deploying your application to a runtime environment.

Changes that do not need redeploy WHEN the application is running with CHECK_FILE_MODIFICATION

• changes in Skinning Stylesheets
• (according to the documentation) changes in JSPs (in my experience, JSP changes are picked up regardless of this setting)

The required setting in the web.xml:

    <context-param>
        <param-name>org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION</param-name>
        <param-value>true</param-value>
    </context-param>

Changes that do not need redeploy WHEN the application is running with debug or fast-swap enabled

• (a limited set of) changes in Java Classes

Changes in classes can be applied to a running application without redeployment under certain circumstances: when the application is running in debug-mode, changes inside existing methods usually are loaded into the running JVM from the IDE. That is one other advantage of frequently using debug mode. Alternatively, when you configure the web application for fast swap (see details in this article), changes in classes are compiled directly into the application server’s ‘exploded deployment directory’ and are picked up by the Application Server immediately. Note that the only a limited set of class changes can be hot-redeployed; it seems that fast-swap is slightly less strict in its limitations.

See this article for how to configure for fast-swap: https://technology.amis.nl/blog/5665/fast-swap-in-weblogic-103-and-jdeveloper-11g-redeploy-after-compile-in-running-application.

Changes that will always require redeployment

These changes will always require a redeployment to be applied:

• faces-config.xml, adfc-config.xml and task-flow definition files
• Page Definition files (and DataBindings.cpx)
• trinidad-config.xml, trinidad-skins.xml and other ADF configuration files
• changes in skin (CSS) definition (unless CHECK_FILE_MODIFICATION is set to true in the web.xml)
• Changes in Resource Bundle files
• Changes in Data Control definitions
• ADF BC meta-data files
• web.xml
• new files of any kind (including images, CSS, JavaScript, JSPX etc.)

Note: some of these changes concerning new files may not need redeployment after all if the new files are copied into the deployment directories on the application server – directories such as C:\bea_middlewarehome\jdeveloper\system\system11.1.1.0.31.51.56\o.j2ee\drs\FastSwapDemo\FastSwapDemo-ViewController-webapp\WEB-INF,