Notes for "Java. util. missingresourceexception can't find bundle for base name"

You know Java is looking for a properties file in a specific locale. you may be baffled why Java keeps complaining it can't find a properties file that is right there. A few things to keep in mind when debugging this type of errors:

1. These resource properties files are loaded by classloader, similar to Java classes. So you need to include them in your Runtime
   Classpath.
2. These resources have fully-qualified-resource-name, similar to a fully-qualified-class-name, excerpt you can't import a resource into your Java source file. Why? Because its name takes the form of a string.
3. ResourceBundle.getBundle("config")Tells the classloader to load a resource named "config" With default package (that is, no package). It does not mean a resource in the current package that has the referencing class.
4. ResourceBundle.getBundle("com.cheng.scrap.config") Tells the classloader to load a resource named "config" With package "com.cheng.scrap."  Its fully-qualified-resource-name is"com.cheng.scrap.config"

For instance, you have a project like




C:/ws/netbeans5/scrap>|   build.xml+---build|   /---classes|       /---com|           /---cheng|               /---scrap|                       Scrap.class|+---src|   /---com|       /---cheng|           /---scrap|                   config.properties|                   Scrap.java

For this statement inScrap.java: ResourceBundle config = ResourceBundle.getBundle("config"); To work, you will needcp src/com/cheng/scrap/config.properties build/classes/ Such thatconfig.propertiesIs directly
Underclasses, And at the same levelcom. Alternatively, you can putconfig.propertiesIntoconfig.jarSuch thatconfig.propertiesIs at the rootconfig.jarWithout any subdirectories,
And includeconfig.jarIn the classpath.

For this statement inScrap.java: ResourceBundle config = ResourceBundle.getBundle("com.cheng.scrap.config"); To work, you will needcp src/com/cheng/scrap/config.properties build/classes/com/cheng/scrap/ Such
Thatconfig.propertiesIs directly underclasses/com/cheng/scrap/, And at the same levelscrap. Alternatively, you can putcom/cheng/scrap/config.properties(Along
With the long subdirectories) intoconfig.jar,and includeconfig.jar in the classpath.  

You may be wondering why it is made so confusing? The benefits are two-fold, as I see it:

1. Location transparency. at runtime, config. properties is not a file, it's just a loadable resource. config. properites may not exist in your project at all, and the person who wrote scrap. java may have never seen this resource. A urlclassloader can find
   It in a network path or URL at runtime. this is especially important for server-side components such as EJB, Servlet, JSP, etc, who are normally not allowed to access file systems. when you ask classloaders for a resource, its physical location becomes irrelevant.
2. Namespace mechanic. Having a package allows multiple packages to have resources with the same short name without causing conflicts. This is no different from Java packages and XML Namespaces.

Translate again. The problem has been solved. When writing your own resource bundle, if you are customizing the messages (such as jmesa or EC) of the open-source framework, it must be clear that resources are read at runtime using classloader, that is, whether the file is being read. the properties file is placed in a folder, and then in the web. in XML, param-value writes the folder path. It should be the write class path, and there cannot be a. properties suffix. Be careful with Web configuration. When writing a folder path with param-value, you cannot forget the forward slash (forward slash), but classpath does not need this.