Nov 1, 2018

Dynamic Reloading of Deployed Modules in Glassfish Server

In the GlassFish Server, dynamic reloading is enabled by default. You do not have to redeploy an application or module when you change its code or deployment descriptors. All you have to do is copy the changed pages or class files into the deployment directory for the application or module. The deployment directory for a web module named context-root is domain-dir/applications/context-root. The server checks for changes periodically and redeploys the application, automatically and dynamically, with the changes.

This capability is useful in a development environment because it allows code changes to be tested quickly. Dynamic reloading is not recommended for a production environment, however, because it may degrade performance. In addition, whenever a reload is done, the sessions at that time become invalid, and the client must restart the session. Copying to a domain’s autodeploy directory lets you put a pre-packaged application into use immediately, with minimal effort. When the server has finished deploying the application, it creates a file named app.name_deployed in the autodeploy directory.

To Reload Changes to Applications or Modules Dynamically on Glassfish server
Glassfish server's Dynamic reloading enables you to change the code or deployment descriptors of an application or module without needing to perform an explicit redeployment. Instead, you can copy the changed class files or descriptors into the deployment directory for the application or module. The server checks for changes periodically and automatically redeploys the changes if the timestamp of the .reload file in the root directory for the application or module has changed.

Dynamic reloading is enabled by default, and is available only on the default server instance.

Create an empty file named .reload at the root of the deployed application or module.


Update the timestamp of the .reload file to load the changes.

In UNIX: touch .reload