Idp v311 installation at non-default loc

[Misagh Moayyed]

+1. I think this will do fine. 

Both tomcat and jetty allow that sort of thing; to allow a complimentary web.xml to load in conjunction with what’s deployed. In fact, I think I already do that sort of thing with jetty to disable directory listings on the default servlet without touching the deployed web.xml. 

- Misagh

> On May 27, 2015, at 1:03 AM, Brent Putman <putmanb at georgetown.edu> wrote:
> 
> 
> 
> 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 <file:///etc/myapp/myapp-spring.xml>" override="false"/>
>   
>   <!-- Custom app-specific param. -->
>   <Parameter name="logbackConfigLocation" value="file:///etc/myapp/logback.xml" <file:///etc/myapp/logback.xml> override="false"/>
> 
> </Context>
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

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