[Esapi-dev] 1.4.4 rc5 ?

[Jim Manico]

 > I think all that I'm asking here is that you switch the order in 
which loadConfigurationFromClasspath() & 
loadPropertiesFromStream(getResourceStream() are called.

I think that is very reasonable. It should not have a negative impact on 
anyone who has been testing this in hard-core production environments.

I'm going to make an exec decision and go for it. This will allow system 
integrators to reliably override developer code.

Anyone object to this strongly? Seems very reasonable and will not 
require classloader priority changing....

- Jim
> [Sorry Jim; meant to CC the list too.]
>
> Jim Manico wrote:
>   
>>> That is too big a change for the 1.4.4 release.
>>>       
>
> I don't think so.
>
>   
>>> And the 2.0 branch allows you to override DefaultSecurityConfiguration.
>>>       
>
> Yes, but one can neither extend or reuse (wrap) the methods that one needs
> to that involve how the ESAPI.properties file is found and loaded. (At least
> if you keep these methods in the reference DefaultSecurityConfiguration
> 'private'.)
>
> I think all that I'm asking here is that you switch the order in which
> loadConfigurationFromClasspath() & loadPropertiesFromStream(getResourceStream()
> are called.
>
> That seems to be a simple change based on this:
>
>         private void loadConfiguration() throws IOException {
>
> 		logSpecial("Attempting to load " + RESOURCE_FILE + " via the classpath.");
> 		
> 		try {
> 			properties = loadConfigurationFromClasspath(RESOURCE_FILE);
> 		} catch (IllegalArgumentException iae) {
> 		
> 			logSpecial("Attempting to load " + RESOURCE_FILE + " via file io.");
> 			try {
> 				properties = loadPropertiesFromStream(getResourceStream(RESOURCE_FILE),
> RESOURCE_FILE);
> 			} catch (Exception e) {
> 				logSpecial(RESOURCE_FILE + " could not be successfully loaded by any means.
> fail.");
> 			}			
> 		}
> 	}
>
>
> Assuming that the ESAPI community approves. If they don't, then I would
> *at* least* want all these 3 methods that do the loading are changed from
> 'private' to 'protected'. Then it would be easy to do in 2.0 myself by
> overriding loadConfiguration(). But it, as well as the two other methods,
> loadConfigurationFromClasspath() & loadPropertiesFromStream(getResourceStream()
> need to be accessible for extending and overriding. And making these protected
> would only have to be in the 2.0 ESAPI version. You do that and I'll vote +1000
> to keep your 'BOO-YA' ;-)
>
> -kevin
>   


-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net