Question
Does Thymeleaf offer a built‑in way to automatically invalidate its template cache when files change?
Rahul Finch
0 reputation · 04 Nov 2021, 08:37 UTC
133.6K views
Loading…
0 reputation · 04 Nov 2021, 08:37 UTC
When developing with Thymeleaf, teams often need to see template edits reflected immediately without restarting the application. The default configuration caches parsed templates for performance, and Thymeleaf itself does not provide a file‑watching mechanism to trigger cache invalidation automatically.
Disabling the cache (setting cache=false) guarantees up‑to‑date templates but introduces noticeable overhead, making it unsuitable for production. Integrators must therefore decide whether to rely on external tools (e.g., Spring Boot DevTools), implement a custom TemplateResolver that clears the cache on file‑system events, or accept a manual cache clear. The lack of a standardized callback for notifying the TemplateEngine that a specific template has been updated leaves this decision unresolved.
Which approach provides the most reliable automatic cache invalidation across different deployment types (WAR, embedded servlet container, cloud)? Is there a recommended pattern for integrating a file‑watch service with Thymeleaf’s TemplateEngine without compromising thread safety or introducing stale template views?
No. Thymeleaf does not provide a built-in file-watching mechanism to automatically detect changes on the disk and invalidate specific entries in its template cache. The engine operates on a binary caching model: it either caches the parsed template indefinitely (until a restart) or it does not cache it at all.
Because there is no native "auto-reload" trigger, the reliable approach depends entirely on your environment. There is no single pattern that works across WARs, embedded containers, and cloud environments without external tooling.
The most reliable method for local development is to disable the cache entirely. In a Spring Boot environment, add the following to your application.properties:
thymeleafspring.thymeleaf.cache=falseThis forces the TemplateEngine to re-parse the file on every request. While this introduces overhead, it is the only way to ensure immediate reflection of changes without a restart.
For those using Spring Boot, spring-boot-devtools provides a more comprehensive solution. It monitors the classpath for changes and triggers an application restart (or a context refresh), which naturally clears the Thymeleaf cache. This is generally preferred over manual cache management as it handles other resource updates (like CSS/JS) simultaneously.
In production, caching must remain enabled. Attempting to implement a custom file-watch service to call templateEngine.clearTemplateCache() is generally discouraged for the following reasons:
To verify your current caching behavior:
spring.thymeleaf.cache=false.true and repeat; the change will not appear until the application restarts.Diagnostic Detail: Are you deploying as a standalone JAR/WAR or using a specialized cloud filesystem (e.g., AWS EFS)? This determines whether a custom TemplateResolver is even technically feasible.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 04 Nov 2021, 17:24 UTC
One option the discussion hasn't covered: in Thymeleaf 3, the template resolver supports a per-entry time-to-live (setCacheTTLMs). Setting a small TTL — say one to five seconds — in a dev profile keeps caching enabled while guaranteeing edits appear shortly after save, without a restart or a file watcher. It's a reasonable middle ground between cache=false (re-parse on every request) and indefinite caching.
That said, no TTL or watcher helps if templates are archived. In a fat jar or WAR, templates live inside the classpath archive, and the JVM cannot reliably observe changes to those entries — so WatchService-based invalidation only makes sense for exploded directories or an external templates folder. For immutable cloud deployments, gating cache=false or a short TTL behind a dev profile is the robust choice. Verify the exact API names against your Thymeleaf and Spring Boot versions, since they differ across generations.