MessageSourceAutoConfiguration fails to read messages.properties when running an executable jar with name starting with "spring-boot-"

[britter]

When MessageSourceAutoConfiguration looks for messages.properties it tries to load all classpath resources using MessageSourceAutoConfiguration$SkipPatternPathMatchingResourcePatternResolver.doFindAllClassPathResources(String). In my case I'm working on an application called spring-boot-heroku-demo, so it will also filter the root classpath resource URL [jar:file:/Users/bene/workspace/projects/spring-boot-heroku-demo/target/spring-boot-heroku-demo-0.0.1-SNAPSHOT.jar!/] because file name returned by that resource is "spring-boot-heroku-demo-0.0.1-SNAPSHOT.jar!/" which starts with "spring-boot".
It works when running the application from an IDE for example, because in this case resources will be loaded from the file system and not from the jar, so a completely different code path is taken to find the messages.properties file.

Possible solutions:

• Document that "spring-boot-" is a reserved project prefix which must not be used.
• List all spring-boot projects with full name in the SKIPPED array in MessageSourceAutoConfiguration$SkipPatternPathMatchingResourcePatternResolver
• Match against the full path of each resource being checked - spring boot project jars will always be included in the lib/ directory.
• None of the above - the described use case is unlikely to affect any other users.

I'm happy to contribute a patch. Please let me know which solution you'd like to use.

[britter]

A possible workaround for this is to set build.finalName in a maven based build to something not starting with "spring-boot-".

[snicoll]

I am not sure, the current situation looks quite wrong to me. Here are my thoughts on your proposals:

1. Not an option (per the bug label added unless someone else disagrees)
2. Maybe
3. It doesn't change the fact you may have a library with that prefix that you include in your spring boot app. To me it fixes your particular use case but not the underlying problem.

I guess the wildcard scanning is the problem in the first place. Maybe we can change that or we could bring a configuration option that would whitelist a given name (spring-boot-heroku-demo). Yet, having to do that is very weird (you have to know about it!).

I am afraid we'll have to give it more thoughts as fixing this one does not look straightforward to me.

[britter]

Option 2 might become a maintenance nightmare. One has to remember to extend the SKIPPED array when new spring-boot projects are added. So although I've suggested it, I don't think it is a good fix.

It doesn't change the fact you may have a library with that prefix that you include in your spring boot app. To me it fixes your particular use case but not the underlying problem.

Good point, didn't think about that.

Maybe we can change that or we could bring a configuration option that would whitelist a given name (spring-boot-heroku-demo). Yet, having to do that is very weird (you have to know about it!).

Yes, and the list might become long if you happen to use several project with the spring-boot prefix (or any other prefix listed in the SKIPPED array).

I am afraid we'll have to give it more thoughts as fixing this one does not look straightforward to me.

Fine by me. The workaround I described above, works for me. Thank you for looking into this on short notice.

[philwebb]

My vote would be a variation on 2) and switch SKIPPED to a set of regex patterns that we can tighten up. The reason that these were added in the first place was as a performance optimization, as long as for production apps we skip common library jars, we shouldn't see any performance regression.

[snicoll]

The reason that these were added in the first place was as a performance optimization

Maybe we could try to fix that instead (moving the location or how it is discovered).

[philwebb]

See #4930

[philwebb]

We've decided to change the message.properties detection logic removing the need entirely for the custom pattern resolver. Fixed in e520c47

[britter]

Nice, thanks!