When the CMS runs in a docker container on a Windows based system, and the packages directory is mounted from the host into the container, changes to files in the packages directory are not propagated as inotify
events, and therefore the default watcher implementation (WatchServiceWatcher) cannot be used. This setup requires the usage of the FileMonitorWatcher.
1 Activate Feature
The feature must be activated in the CMS configuration:
feature: devtools: true
After activating/deactivating the feature or changing other configuration settings, it is necessary to reload the configuration for the changes to take effect.
2 Watcher implementation
The automatic synchronization of files changed in the filesystem with the objects in the CMS is based on a mechanism to detect filesystem changes.
There are two different implementations of this mechanism.
2.1 WatchServiceWatcher (default)
This implementation listens to filesystem events (e.g. inotify on linux based systems). This implementation (which is the default) is best suited for installations, where the packages directory is located on a native filesystem or where the the packages directory is mounted using a technology which supports those filesystem events.
This watcher implementation can be activated with
devtools: synchronizer: class: "com.gentics.contentnode.devtools.WatchServiceWatcher"
2.2 FileMonitorWatcher
This implementation uses polling to detect changes in the monitored directories and will work in all scenarios. However, it has the disadvantage to create some permament CPU load caused by the polling (as long as the devtools
feature is activated).
This watcher implementation can be activated with
devtools: synchronizer: class: "com.gentics.contentnode.devtools.FileMonitorWatcher" interval: 100
The setting devtools.synchronizer.interval
defines the polling interval in milliseconds (default is 1000). Longer intervals produce less CPU load but cause a longer delay for the change detection. Shorter intervals allow for faster detection but increase the CPU load.