We recently upgraded from brXM 15 to 16 (Java 17, Tomcat 10.1, Spring 6 / Jakarta) and ran into the question of what to do with the hst-spring-support forge module. We use its HstRepositoryResourceBundleMessageSource so repository resource bundles are available as a regular Spring MessageSource.
As far as I can tell the module is effectively end-of-life. The last release is 2.0.1 from January 2019, the compatibility matrix stops at brXM 13.x / Spring 5.x, and the jar is built against javax.servlet, so it cannot run on a Jakarta stack at all. HST - Spring Framework Support Documentation – Release Notes
For the upgrade we copied the relevant classes into our own project and updated them for Jakarta. That works, but now the maintenance is on us. And if you go this route, one tip: keep the getStringOrNull override that’s shipped with the forge class.
protected String getStringOrNull(ResourceBundle bundle, String key) {
try {
return bundle.getString(key);
} catch (MissingResourceException ex) {
return null;
}
}
This override isn’t cosmetic. It was added deliberately in 1.1.2 for HIPFORGE-129.
Without it, Spring first calls bundle.containsKey(key). On HST’s CompositeResourceBundle, that ends up in handleKeySet(), which walks every key in every child bundle. A miss in handleGetObject will throw a MissingResourceException.
That’s fine when the list of bundles is small, but it gets expensive when hst:defaultresourcebundleid contains a long list. Worse, nothing actually breaks, so tests are unlikely to catch the regression.
What’s the recommended setup for repository bundles in Spring on brXM 16 and later?
-
Porting the forge classes into your own project, as we did? Or dropping the Spring bridge and using ResourceBundleUtils.getBundle(basename, locale) directly? Direct access is simpler, but every caller then needs to know the bundle name, and templates using spring:message and bean-validation messages still need a MessageSource.
-
Is there a Jakarta-compatible version of hst-spring-support that I’ve missed?
-
Could this be fixed upstream? CompositeResourceBundle.handleGetObject already returns null for missing keys, so an override of containsKey or handleKeySet there would avoid this problem, since getKeys() already computes the merged key set. At the least a warning in the upgrade documentation would help.
Thanks
Mehul Parmar