ApplicationContextInitializer and contextConfigLocation ?

Brent Putman putmanb at georgetown.edu
Thu Jun 12 18:52:56 EDT 2014


On 6/12/14 6:08 PM, Tom Zeller wrote:
>
> A contextConfigLocation with "${idp.home}" will not load because the
> property cannot be resolved.

Ok, right.  I thought I recalled seeing a RuntimeException being thrown
somewhere for that.

>  With "${idp.home:}" the context will
> load, but then the property is replaced with "" so it cannot be
> resolved again via setConfigLocations(getConfigLocations()). 

Ok, bummer.


> So, I
> guess we would have to use "${idp.home:REPLACE_ME}" or something 

Yeah, you could do that.  Or in web.xml you could just use a replace
token that isn't a Java property token at all, instead something
specific and understood only by the context initializer.  Like
"@@IDP_HOME@@/system/conf/global-system.xml"


> but
> that seems ugly in comparison to just setting idp.home as a system
> property.

I guess beauty is subjective. :-)   If the only place a proprietary
token would appear is in web.xml, that nobody ever really touches, then
it might not be that bad.

Yes, you could require that that be set as a system property before
starting the container.  I actually thought you were going to do
something like that anyway, but your question implied you wanted to find
a way to not do that (i.e. to support an idp.properties property or
whatever instead, that Scott wanted, and have the ACI do processing to
produce idp.home).


Another idea:  Since the problem with the above is the way that property
replacement is done on the config locations when you call
context.setConfigLocations(), you could just use a custom subclass of
the default web application context type, and override either its
setConfigLocations() or maybe its resolvePath() or something.  Note that
you can specify the type of root context that it will create using the
'contextClass' servlet context param in web.xml. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140612/b05d8b2c/attachment.html 


More information about the dev mailing list