Hot reload involves a lot of layers, each one handling different kinds of caches. Server tries to keep contextual information which are not persisted and reload every services to take into account changes in Java code.
Hot reload is currently mainly interesting to ease up development. Enabling it means re-building part of the application, resetting caches that are needed for the application to work efficiently, etc. For this reason, using hot reload may not be suitable for production.
Hot reload support is controlled by the Nuxeo development mode. This mode can be activated by setting a runtime property in
nuxeo.conf file (you'll need to restart your Nuxeo server):
When contributing a JAR to the Nuxeo application, what's a stake?
- The JAR should be detected by the application.
- Its contributions to Nuxeo extension points should be loaded.
- Its contributions to other resources (XHTML files, message bundles, etc...) should be detected.
- Some caches should be reset.
For this you need the
java.io.File of your bundle, and you can call:
Undeploy and deploy to the runtime framework were already possible as of Nuxeo 5.4.1: you can take example on what the
ReloadService is doing to make it work in your version.
Note that reloading a bundle is working correctly only if the extension point registries it holds are correctly handling the contributions merging and removal. This can be easily set up by extending the Descriptor interface and implementing the
The WAR is rebuilt after each reload, taking care of changes to
JARs/bundles deployed in the application:
When the WAR is up-to-date, it's a matter of forcing the application to detect changes.