loading from the root of the application was broken

[JoergAdler]

Hi,

with 2.2.0-RC2 a esapi.properties in the root of the application wasn't loadable anymore. I've done a fix for this.

[JoergAdler]

Sorry for the whitespace changes. It seems, that my eclipse is doing weird things :-(

[kwwall]

Also, general comment: Make sure your file modifications are saved using UTF-8 encoding with only newlines for the line terminator (i.e., UNIX style line terminators). We have tried to standardize on tabsize of 4 with tabs expanded to spaces as well. It helps if you have this in your $HOME/.gitconfig file:

        [core]
            autocrlf = input

[kwwall]

@xeno6696 Can you confirm that this is the correct value?

[xeno6696]

Doesn’t look right. I would have just restored the value I clobbered in the if block

[JoergAdler]

Unfortunately it is the right value. As you can read here:
http://www.thinkplexx.com/learn/howto/java/system/java-resource-loading-explained-absolute-and-relative-names-difference-between-classloader-and-class-resource-loading

"There are ClassLoader.getResource() and Class.getResource() and they work differently [...] The name should not have a leading “/”."

Please also check the new added test in DefaultSecurityConfigurationTest.

[xeno6696]

@JoergAdler Sorry for the delay. My concern is that what you did here, isn't what was done in the past:

					// try root directory path given by user
					if (in == null){
						in = loaders[i].getResourceAsStream(fileName);
					}
					

Which looked erroneous to me, but it IS what we were doing. I think if we at least re-include that case I'm fine with the rest of the changes. I'm still not sure why that case was referred to as "root." I wanted to debug the old 2.1.0.1 release but that would have required me getting an older JDK and I didn't care all that much.

[kwwall]

It has been too long and the author of this PR has not responded. I am still going to include this fix in the 2.2.0.0 release, but I can wait no longer for the PR to get cleaned up (all the white-space diffs, plus the new property file really only needs a single property in it), so I am going to reject this PR. I will still credit @JoergAdler in the 2.2.0.0 release notes though as contributing toward the fix. Thanks Jörg.

[JoergAdler]

Hi,

Sorry that I not responded for a long time.

When I get it right, the following problems still exists in the pull request: formatting and the property file should have only one property.

If you want, I could fix still fix this and reopen the pull request?

Feel also free to edit the pull request in my fork.

[kwwall]

No worries. I've already made the changes based on your changes and tests, added some comments and additional tests, reduced the ESAPI-root-cp.properties file to a single property (and, it turns we really didn't need it to test this; using
new DefaultSecurityConfiguration("esapi/SingleValidatorFileChecker.properties")
or something similar works as well. But I kept your file and just added a second test for something like that latter. I will mention you in our release notes though.

Oh, one last thing. @xeno6696 mentioned in #489 (comment) that:
in = loaders[i].getResourceAsStream(fileName);
Since the enum ROOT now has a value of an empty string, that is in fact now logically equivalent to your fix of:
in = loaders[i].getResourceAsStream(DefaultSearchPath.ROOT.value() + fileName);

So that makes we feel a lot better about all this. But like I said, I already extracted your changes from your PR and pulled them into my commits, so don't sweat it.

I'm pretty much done with everything other than closing out a couple of more issues and updating the release notes, but I'm hoping that I should have the official 2.2.0.0 release out sometime late Sunday evening if all goes to plan.