org.jboss.as.controller.descriptions.StandardResourceDescriptionResolver relies on the default loading mechanism in java.util.ResourceBundle: first search for java-class-based resource, then properties file based resources. In WildFly core and proper, all management resources use properties file. So the loading of the non-existent java-based resource bundle always fails and we should be able to avoid this futile trial.

Fallback to the default locale is also something we can get rid of. When the resource bundle for specific locale is not found, java.util.ResourceBundle falls back to the default locale. If that fails, it finally falls back to the base-name resource bundle. I think we should directly fall back to the base-name resource bundle.

In most cases, we already call getBundle() passing the current locale (from Locale.getDefault()). So there is no need to fall back to default locale for a second try.

Even if the designated locale is different than the default locale, it's hard to say whether default locale, or base-name (en_US) is better fit. I think base-name is probably better. For instance, in a French machine, you're requesting resource bundle in es. When es is not available, do you want to read Fr (the default locale), or en (the base name)?