When is a file not a file? When it's part of a WAR!
A WAR is a ZIP file, and while technically we call the things stored within a ZIP, "files", they aren't files in the sense that a general file system can issue open/close/read/write calls directly on them. In a WAR context, I prefer to refer to them as "resources".
The issue is further confused because some webapp servers (such as Tomcat) support an "exploded WAR" where the WAR is unzipped, and therefore the "files" in the WAR are actually present as real files in the filesystem. But it's bad practice to depend on WAR resources being physical files because the J2EE standard does not support that concept.
However, here's what you need to do:
First, don't put your properties in the WAR root. That makes them visible from web browsers, and that's a possible security concern. You can hide stuff by putting it under the WEB-INF directory.
In a general case, such as images, you could create a directory such as "WEB-INF/images" and put your image resources in that directory. Then get the HttpServletRequest from the FacesContext and use getResourceAsStream() to obtain the handle you need to read the resource contents. The Resource pathname would be "/WEB-INF/images/picture1.jpg", for example. Note that you don't need to know the URL or the context name of the webapp, as the getResource/getResourceAsStream methods assume that the root is always going to be the top of the WAR, regardless of how and where it's deployed.
In the case of properties, however, I believe you can go one better, since unless I'm mistaken there's an api method for getting property files directly from the classpath - meaning you'd put the properties in /WEB-INF/classes or one of its subdirectories. I can't remember if it's a straight shot or if you have to have a classloader as a reference point, however. If you need a classloader, usually you can just obtain the classloader from the executing code's this.getClass().
An IDE is no substitute for an Intelligent Developer.