Q:

Where does ESAPI.properties go in a Java Google AppEngine project

My project is working on the development server. It works in both the following cases:

With the .esapi directory in the source path, so that it ends up in WEB-INF/classes
With the .esapi directory in the lib root, so that it ends up in WEB-INF/lib

However, it doesn't work when deployed to Google (using either of the above 2 strategies).
I get usual messages about not being able to find the ESAPI. properties file when I first try to use ESAPI once deployed to Google.
Attempting to load ESAPI.properties via file I/O.
Attempting to load ESAPI.properties as resource file via file I/O.
Not found in 'org.owasp.esapi.resources' directory or file not readable: /base/data/home/ap
Not found in SystemResource Directory/resourceDirectory: .esapi/ESAPI.properties
Loading ESAPI.properties via file I/O failed. Exception was: java.io.FileNotFoundException
Attempting to load ESAPI.properties via the classpath.
ESAPI.properties could not be loaded by any means. Fail. Exception was: java.security.Acces

ESAPI does appear to include changes to support AppEngine http://goo.gl/rD8dz
Update
The issue is that line 603 of org.owasp.esapi.reference.DefaultSecurityConfiguration calls ClassLoader.getSystemClassLoader() which is illegal in Google Appengine. This causes the exception above (sorry it's cropped).
There are three ClassLoaders loaded into an array upfront, before the code tries to get the resources.
    ClassLoader[] loaders = new ClassLoader[] {
            Thread.currentThread().getContextClassLoader(),
            ClassLoader.getSystemClassLoader(),
            getClass().getClassLoader() 
    };
    String[] classLoaderNames = {
            "current thread context class loader",
            "system class loader",
            "class loader for DefaultSecurityConfiguration class"
    };

I've hacked in my own copy of DefaultSecurityConfiguration where I've removed the SystemClassLoader (and corresponding classLoaderName) from the loadConfigurationFromClasspath method.
    ClassLoader[] loaders = new ClassLoader[] {
            Thread.currentThread().getContextClassLoader(),
            getClass().getClassLoader() 
    };
    String[] classLoaderNames = {
            "current thread context class loader",
            "class loader for DefaultSecurityConfiguration class"
    };

Ironically it's because they've made the code easy to read/extent (IMHO) by looping through Classloaders that this approach fails. I'm tempted to submit a patch with an inner class to delay the call to getSystemClassLoader (which you can't do on AppEngine).
It's interesting that this works as it's only possible because the esapi jar is not sealed.
I'd have thought a security library jar should be sealed. Maybe I'm using the wrong one!
Update
I'm using the esapi jar via maven, this has been repackaged and isn't signed. Not ideal, but it's no less secure than the other 40 open source jars I'm getting from maven!

A:

Your solution of overriding the DefaultSecurityConfiguration class with your own implementation is precisely the correct way to address the problem. This is precisely the reason that it is designed this way. There are some other inherent problems with using ESAPI on Google App-Engine tho, primarily with regards to encryption/hashing. This issue has been "partially" resolved according to comments on this thread (http://code.google.com/p/googleappengine/issues/detail?id=1612) but there are still serious limitation on using encryption in GAE.

A:

I just successfully integrated ESAPI 2.1.0 on a Google App Engine Project and I did not even use Maven for it.
Put the ESAPI.properties & validation.properties in the directory [gae-project]/war/ESAPI/.
Thus, the full path of the ESAPI.properties will be
[gae-project]/war/ESAPI/ESAPI.properties

Putting it under the war/ ensures that the files will be uploaded to Google.
Edit your appengine-web.xml, add the following lines inside the <appengine-web-app> root node
...
<system-properties>
    <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" />
    <property name="org.owasp.esapi.resources" value="ESAPI" />
</system-properties>
<static-files>
    <exclude path="/ESAPI**properties" />
</static-files>
...

that will allow App Engine to recognize .properties files as project files.
for a more detailed discussion you can also read ESAPI for Google App Engine Integration Tutorial

