<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 5/26/15 4:19 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:9EFF44C2-6D80-4A47-93A3-A350F781C59E@osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
I would like it if we made it possible to do, without explicitly requiring it, and one thought I had was to allow the searchLocations set for idp.home to be overridden in web.xml. So you don't really need to set idp.home there but if you have some embedded use case for driving the location there, you just tell it to search a different set of locations for the configuration.</pre>
</blockquote>
<br>
I agree it would be nice.<br>
<br>
<br>
<blockquote cite="mid:9EFF44C2-6D80-4A47-93A3-A350F781C59E@osu.edu"
type="cite">
<pre wrap="">
But for the archive, no, V3 installation no longer does any changing of XML files at install time, web.xml or otherwise. It's only property merging now.
</pre>
</blockquote>
<br>
I also like it that we don't do that any more, it seems cleaner to
me.<br>
<br>
Just wanted to note that these are not exclusive options, depending
on container support. Tomcat allows one to set servlet context
params *externally*, as part of the context fragment deployment
descriptor, without touching the deployed webapp or its web.xml. (I
think Jetty does also, but have never used.) I have used this
technique a lot to accomplish the same kinds of things we're doing
with setting the idp.home as a system property. But this has the
advantage that the property is localized to the particular web app,
not a global system prop; so can have different values for different
instances of the webapp if you have more than one in the same
container. It's also more J2EE-y. It's very easy. Example below. <br>
<br>
So if our context initializer can be made to check a idp.home
context param, in addition to its well-known ones, one can have the
best of both worlds, without even modifying web.xml.<br>
<br>
As an aside, I double-checked and I believe that modern versions of
Spring already configure a PropertySource for a
WebApplicationContext that provides access to the servlet context
params. So I think a simple change to
IdPPropertiesApplicationContextInitializer to make it look for
idp.home that way before it consults the well-known locations (or
just add it to the front of the list) would make all this work. I
think...<br>
<br>
Tomcat context fragment:<br>
<br>
<tt><?xml version="1.0" encoding="UTF-8"?></tt><tt><br>
</tt><tt><Context docBase="/path/to/myapp.war" ></tt><tt><br>
</tt><tt><br>
<!-- Add an external Spring beans file to the standard one
living in WEB-INF. --><br>
</tt><tt> <Parameter name="contextConfigLocation"
value="/WEB-INF/applicationContext.xml <a class="moz-txt-link-freetext" href="file:///etc/myapp/myapp-spring.xml">file:///etc/myapp/myapp-spring.xml</a>"
override="false"/></tt><tt><br>
</tt><tt> </tt><tt><br>
<!-- Custom app-specific param. --><br>
</tt><tt> <Parameter name="logbackConfigLocation"
value=<a class="moz-txt-link-rfc2396E" href="file:///etc/myapp/logback.xml">"file:///etc/myapp/logback.xml"</a> override="false"/></tt><tt><br>
</tt><tt><br>
</tt><tt></Context></tt><br>
<br>
</body>
</html>