Hi,
the Spring Boot propertie :
spring.messages.basename=[directoy_in_resources]/messages does not work
I have this arborescence in my project :
I have workaround this by write a :
@Bean
public MessageSource messageSource() {
ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
messageSource.setBasename("messages/messages");
messageSource.setDefaultEncoding("UTF-8");
return messageSource;
}
But it's seem a little heavy way, no ?
Why I can't write this in application.properties :
spring.messages.basename=messages/messages
Thank's for all
Rick
Comment From: snicoll
There's certainly a test that exercises the scenario I understood from your description and it passes.
It seems a bit odd to me that copy/pasting the same information in a custom bean fixes the problem for you. If we want to make some progress, we'll need a small sample that reproduces the problem you've described. You can do so by attaching a zip to this issue or sharing a link to a GitHub repository.
Comment From: tarhack
Ok, I package a simple project for you.
Comment From: tarhack
Comment From: tarhack
1/ Start Application.java 2/ goto http://localhost:8083/snic 3/ This project work, BUT the Spring Boot propertie : spring.messages.basename=messages/messages does NOT work
Comment From: tarhack
see:https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html
Comment From: snicoll
Thanks for the sample.
This resource bundle doesn't have a messages.properties
, which we use as a signal to verify that this feature should be enabled. Please refer to the reference guide for more details.
I've renamed messages_en.properties
to messages.properties
and commented out your custom bean definition and the sample now works for me. I suggest regardless to have a default properties (i.e. messages.properties
) in your resource bundle.
Having said all of that, you're also configuring a custom basename which we could use a strong signal that you want to use this feature. I've flagged this issue for team attention to see if we want to relax the condition a bit and create that bean if a custom base name is set and no default properties is available.
Comment From: tarhack
Thank you for your your quick reply. Work fine ! Yes this feature can be very useful in "Spring Boot" mind which reduce code and replace it by properties. Merci pour tout !
Comment From: tarhack
It work even with an empty messages.properties ...
Comment From: tarhack
I guess I'm the one closing this incident
Comment From: wilkinsona
We added the requirement for a default properties file in https://github.com/spring-projects/spring-boot/issues/4930 for performance reasons. We also believed that having a default properties file as a fallback is good thing to do. IMO, both of these still hold true. If we want to change one or both of them, I think it should be done irrespective of whether or not the base name has been customised as I don't think a custom base name can be used as a signal that performance is no longer important or that having a default properties file as a fallback is no longer a good thing to do.
Comment From: tarhack
Ok, thank you for answer.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Garanti sans virus. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Le mer. 24 févr. 2021 à 12:44, Andy Wilkinson notifications@github.com a écrit :
We added the requirement for a default properties file in #4930 https://github.com/spring-projects/spring-boot/issues/4930 for performance reasons. We also believed that having a default properties file as a fallback is good thing to do. IMO, both of these still hold true. If we want to change one or both of them, I think it should be done irrespective of whether or not the base name has been customised as I don't think a custom base name can be used as a signal that performance is no longer important or that having a default properties file as a fallback is no longer a good thing to do.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-boot/issues/25398#issuecomment-785019380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF6JZM52FGUK6YT4JFKI6Y3TATRDNANCNFSM4YCSBV5A .
-- A+
TRK
Comment From: tarhack
Ok, thank you all.
Comment From: snicoll
Thanks @wilkinsona. Having a default properties file as a fallback being our recommendation is key in this, I think. I agree this would set a weird precedent and given things are properly documented in the reference guide, I agree we're good with the current state.