<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 6/12/14 6:08 PM, Tom Zeller wrote:<br>
</div>
<blockquote
cite="mid:CAMNmQDRhnsWAQtJ4LBGGDeTQ3ueRFOJ_OTsyfa4JzL=Pfffz1g@mail.gmail.com"
type="cite">
<pre wrap="">
A contextConfigLocation with "${idp.home}" will not load because the
property cannot be resolved.</pre>
</blockquote>
<br>
Ok, right. I thought I recalled seeing a RuntimeException being
thrown somewhere for that.<br>
<br>
<blockquote
cite="mid:CAMNmQDRhnsWAQtJ4LBGGDeTQ3ueRFOJ_OTsyfa4JzL=Pfffz1g@mail.gmail.com"
type="cite">
<pre wrap=""> With "${idp.home:}" the context will
load, but then the property is replaced with "" so it cannot be
resolved again via setConfigLocations(getConfigLocations()). </pre>
</blockquote>
<br>
Ok, bummer.<br>
<br>
<br>
<blockquote
cite="mid:CAMNmQDRhnsWAQtJ4LBGGDeTQ3ueRFOJ_OTsyfa4JzL=Pfffz1g@mail.gmail.com"
type="cite">
<pre wrap="">So, I
guess we would have to use "${idp.home:REPLACE_ME}" or something </pre>
</blockquote>
<br>
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
<a class="moz-txt-link-rfc2396E" href="mailto:@@IDP_HOME@@/system/conf/global-system.xml">"@@IDP_HOME@@/system/conf/global-system.xml"</a><br>
<br>
<br>
<blockquote
cite="mid:CAMNmQDRhnsWAQtJ4LBGGDeTQ3ueRFOJ_OTsyfa4JzL=Pfffz1g@mail.gmail.com"
type="cite">
<pre wrap="">but
that seems ugly in comparison to just setting idp.home as a system
property.
</pre>
</blockquote>
<br>
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.<br>
<br>
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).<br>
<br>
<br>
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. <br>
<br>
<br>
</body>
</html>