While building a native image for a Spring Boot application that uses MessageSource and message.properties files I noticed that those are not registered as resources during the native image compilation by default.
After explicitly adding them to a resource-config.json file they were available in the native image. However I would have expected Spring Boot to provide a RuntimeHintsRegistrar implementation out-of-the-box that contributes these properties files automatically.
Is it reasonable to add such a RuntimeHintsRegistrar implementation?
Comment From: philwebb
I seem to remember there was some discussion about this in the past, but I can't find it now. I think if we do add hints the registrar should probably be in Spring Framework and react to AbstractResourceBasedMessageSource beans.
@bclozel could you please transfer this issue?
Comment From: sdeleuze
@philwebb @bclozel I am not sure to understand how we can handle this on Spring Framework side because, at AOT stage, I don't think we have access to MessageSource bean instances, and the basename is not available in the bean definition, but hidden in org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration#messageSource BeanInstanceSupplier.
As far as I can tell, the only chance we have is to introduce the relevant hints (something like resourceHints.registerPattern(baseName + ".properties").registerPattern(baseName + ".xml"); at Boot level based on the message source configuration property.
Any thoughts?
Comment From: philwebb
No, I think you're right. I was originally thinking that we could inspect the ResourceBundleMessageSource, but I think it's too risky to initialize that bean early.
Sorry @bclozel, could you transfer this back again?
Comment From: beckermarc
I suggested a fix for this at least for the default MessageSource basename in #36682. I noticed that this approach is also taken in some other places, e.g. for schema.sql and data.sql. In my scenario this simple fix would be sufficient, as we use the defaults.
Comment From: wilkinsona
Closing in favor of #36682. Thanks for the PR, @beckermarc!