Configuration reloading via Tomcat 7 parallel deployment ?

[Tom Zeller]

A reach, I know, but when I think about configuration reloading, I
wonder if something like parallel deployment [1] in Tomcat 7 is, well,
worth talking about.

Rod and I talked about our Service interface as regards resource
reloading today, and I wonder if spinning up a new web app instance is
an alternative to the v2 way of replacing a Spring application context
with a new one.

I do not see parallel deployment feature parity in Jetty, not sure if
anyone has experience with Tomcat's.

>From what I understand, parallel deployment in Tomcat involves
deploying a war with a filename like "foo##<Major.Minor.Patch>.war",
and Tomcat maps requests to app##<version>.war via a <version> string
appended to the session ID. The functionality, I guess, was written
for a commercial product based on Tomcat but which was then donated to
the project because some changes required were so core.

I hesitate to bring up questionable ideas, but I had floated the "idp
front end" notion, which really is the same thing - spin up a new web
app and "gracefully" move requests over.

>From what I can tell, we do not recommend reloading relying-party.xml
[2], and it looks like attribute-filter.xml is the most frequent
candidate, then attribute-resolver.xml.

So, maybe lessen the scope for configuration reloading to attribute
components and logging, and continue to find ways to support upgrading
or re-configuring the IdP as a web app.

[1] https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment
[2] http://shibboleth.net/pipermail/users/2011-August/000425.html

Thoughts ?