Idp v311 installation at non-default loc

Brent Putman putmanb at georgetown.edu
Tue May 26 17:03:18 EDT 2015



On 5/26/15 4:19 PM, Cantor, Scott wrote:
> 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.

I agree it would be nice.


> 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.

I also like it that we don't do that any more, it seems cleaner to me.

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.

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.

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...

Tomcat context fragment:

<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="/path/to/myapp.war" >

  <!-- Add an external Spring beans file to the standard one living in
WEB-INF. -->
  <Parameter name="contextConfigLocation"
value="/WEB-INF/applicationContext.xml
file:///etc/myapp/myapp-spring.xml" override="false"/>
 
  <!-- Custom app-specific param. -->
  <Parameter name="logbackConfigLocation"
value="file:///etc/myapp/logback.xml" override="false"/>

</Context>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150526/4b887d6d/attachment.html>


More information about the users mailing list