Allow for different implementations of SecurityConfiguration

[GoogleCodeExporter]

We need a flexible configuration service  in 2.1 to provider generic 
features for default and custom providers.  In regards to loading 
configuration files, I think the following are needed:

1) Deployers may wish to adjust the order that class loaders are used in 
the look up.   This is because:

a) App servers all use different class loader hierarchies ( Kevin said 
Websphere uses 5 ) and some such as Weblogic all you to adjust the class 
loader hierarchy in the war's container specific deployment descriptor ( 
weblogic.xml).

b) Different organizations may want to be able to overide system wide 
defaults ( system classpath) for a specific war and this requires looking 
in System class loader after the ThreadContext class loader.

2) We may wish to override the resource search order ( file vs class 
loader).  I can think of a few use cases for this and perhaps building this 
into the service ( i.e. strategy plugin) is a lot easier than requiring 
users to subclass the service.

Original issue reported on code.google.com by manico.james@gmail.com on 28 Jan 2010 at 7:17

[GoogleCodeExporter]

Original comment by manico.james@gmail.com on 1 Nov 2010 at 1:25

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

The configuration mechanism can now be overridded via your own class by setting 
a system property at JVM startuptime

Original comment by manico.james@gmail.com on 3 Nov 2010 at 9:55

• Changed state: Verified