The message is correct, although the idea might seem surprising. Properties files and bundles are intended to be placed in the same directories as your java classes, which means that they can be found on the app's classpath. Treat them exactly like you would treat your classes, which means refer to them using fully qualified "classnames".
For examples, let's say I have an "appResources.properties" file and I want to put it in "WEB-INF/classes/com/mousetech/myapp/resources", since WEB-INF/classes is a fundamental part of any WAR's classpath. The fully qualified resource name would then be "com.mousetech.myapp.resources.appResources.properties".
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: May 01, 2008
Thanks Tim. You are right. I never created a resources file in the source packages. I copied all my properties files under a folder in WebContent and accessed it using the '/'. Yes, we can access it using the fully qualified name of the resource file, when the resource files are under one of the source packages, or even under WebContent. Thanks once again, it was a new piece of information.
Joined: Apr 19, 2008
So if I understood you correctly, build/classes is also on the classpath. So I tried copying my messages.properties to this directory and to the mypackage directory underneath build/classes and
eclipse still complains that it cant find it?
Eclipse is not a web application server. You can install a web application service debugging and control interface into Eclipse, but Eclipse itself doesn't participate. Therefore the build classpath isn't sufficient.
A J2EE web application server needs a WAR, either as a WAR file or the unzipped (exploded) equivalent. The classpath for that WAR is the WEB-INF/classes and the jars in the WEB-INF/lib directory of that WAR. Additional system classpath elements come from the web application server and not from Eclipse.