Can't find bundle for base name config, locale en_US

[2012-09-29 10:19:33] [INFO] 获取数据库连接::Can't find bundle for base name config, locale en_US

[2012-09-29 10:19:33] [ERROR] SmsSubAccountServiceImpl类中的|activeStatus()方法null

ResourceBundle.getBundle("myresource")

如果发生ResourceBundle.getBundle("myresource") 读取不到资源文件时，需要注意下面问题.

1，java project

仅仅需要把myresource.properties文件放在src下，如果是放在package下，则程序的filename应该package/myresource

2，j2ee的web project

1，myresource.properties要放在WEB-INF的classes下，

2，如果是使用jar来执行读取资源文件时，该jar需要添加在lib下面，不仅仅是由IED(eclipse)配置的classpath

 

解释：getBundle加载资源文件时，会读取当前应用的classLoader,遍历当前的classloader找出classpath，进行资源文件的绑定，如果找不到则会报出

java.util.MissingResourceException。

关键在于，如果使用eclipse配置应用，而且是将lib托管给elipse去加载，那么eclipse中启动tomcat时，应用的加载lib下的classloader和tomcat读取应用后加载的class就不会是同一个。

tomcat启动时，根据tomcat配置的jre，加载应用。而且应用的lib托管给eclipse，由elipse设定的jre加载lib下的jar。此时就会有2个jre环境。

解决方法是：把所有jar放到WEB-INF的lib下，由容器自己加载。当然也要在此加载到classpath下，项目编译需要。

 

java.util.MissingResourceException: Can't find bundle for base name

头午写那个程序，人家老大说了，得要配活。。。怎么配活呢。读取一个文本文件，这样就活啦。晕。。。

下午就开始了。。。文件属性及值都搞好了，然而在配属性文件时出现标题的样子错误。然后在网上找呀找。。终于找到了，NND，可惜是英文的，不过俺的英语还能看个八九不离十。。

Solve java.util.MissingResourceException: Can't find bundle for base name com...config, locale zh_CN

at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:836)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:805)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:576)

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 in Scrap.java: ResourceBundle config = ResourceBundle.getBundle("config"); to work, you will need to cp src\com\cheng\scrap\config.properties build\classes\ such that config.properties is directly under classes, and at the same level as com. Alternatively, you can put config.properties into a config.jar such that config.properties is at the root of config.jar without any subdirectories, and include config.jar in the classpath.

For this statement in Scrap.java: ResourceBundle config = ResourceBundle.getBundle("com.cheng.scrap.config"); to work, you will need to cp src\com\cheng\scrap\config.properties build\classes\com\cheng\scrap\ such that config.properties is directly under classes\com\cheng\scrap\, and at the same level as scrap. Alternatively, you can put com\cheng\scrap\config.properties (along with the long subdirectories) into a config.jar, and include config.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 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 mechanism. 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.

才知道那个属性文件也要加上路径的。于是又开始新征程。这样为了配活，再来。

static ResourceBundle rb = ResourceBundle.getBundle(ReadSource.class.getPackage().toString().substring(8)+".info");

这样就解决了路径问题，只要属性文件和读取文件在一起就可以了。它们俩放哪倒是无所谓了。呵呵。