Maven Resources Plugin and Binary Fonts

Copy WAR resources without corrupt binary files

The Maven Resources Plugin copies project resources into the output dir during the creation of the WAR. During this phase the plugin performs the filtering operation, where the variables in the resource files are replaced with the specified values. But this filtering operation does not have to be done for binary files, to prevent these files from being corrupted. For example binary files that can be corrupted by the filtering phase of the Maven Resources Plugin are the fonts.

If there are any corrupted fonts in the deployed WAR, just check with the developer’s tools that each browser provides, if there are any errors in the font decoding phase of the browser itself. For example, as in this case:

fonts_corruptedmessages such as “Failed to decode downloaded font”, or “OTS parsing error: Failed to convert WOFF 2 font to SFNT”, or “incorrect file size in WOFF header”, or “GDEF: invalid table offset” are all signs that binary fonts are corrupt.

To avoid these problems just add the exclusions in the configuration section of the plugin in the pom.xml file. For example:


in this case all files with extensions declared in nonFilteredFileExtensions will only be copied to the output dir without being filtered.


Spring MVC, Spring Boot and Resources Caching

Modern web application and browser resources caching

Modern web applications use a large number of static resources such as js files, css, fonts, images, etc.
Even if the internet connections are always more efficient, it’s always worth asking if it’s useful to use the resources caching, that’s to say to allow the browser to store static resources in its cache. In general it’s better to find the right compromise, since in reality resources can also change such as the application js files (very rarely those of the application stack).

Our web applications are based on Spring Boot and Spring MVC which by default do not allow the caching of resources.
To enable resource caching, you can intervene in the application config files. For example, if we want the cache to have a validity of one week,
you have to add the following line in the file:


If a particular resource handler is used, configure it for caching. For example, for resources loaded with the webjars protocol, we had to configure a resource handler for compatibility issues with Websphere. Even in this case just configure the cache period like this:

public void addResourceHandlers(ResourceHandlerRegistry registry) {
setCachePeriod(604800).resourceChain(true).addResolver(new WebJarsResourceResolver(new WasWebJarAssetLocator()));

To force the cache to refresh before expiry of the validity period (for example, if you release a new version of the application that requires changes substantial in the js files) two techniques can be used. On the client side, you can force the cache to be refreshed with the classic << Shift + F5 >> from the browser. On the server side you can use the file versioning technique, adding the version in the file name.