IdP 2.4.5 does not work on recent Tomcat 7 and its workaround

Cantor, Scott cantor.2 at
Fri May 20 14:53:48 EDT 2016

> There are many classpath: URIs in the following files so you should modify all
> the URIs.
> service.xml
> opensaml-2.6.6.jar
> shibboleth-common-1.4.5.jar
> shibboleth-identityprovider-2.4.5.jar
> xmltooling-1.4.6.jar

There are a ton of insanely complicated interactions here, and there are issues with Spring and how the system is dealing with those schemas. A change like this could conceivably fix one issue, but end up creating a problem in another spot. It's a big issue, is what I'm saying.

The use of that classpath: syntax was something Chad sort of invented but did it by essentially copying a convention that other projects have been using in weird and often not exactly compatible ways. It's one of the reasons we support but do not encourage deploying V3 in a way that relies on classpath lookup of resources. It's very hard to make it work reliably.

V3 has code in place to support those classpath URIs but no longer requires them to avoid remote lookup of schemas. But I would not be confident that it couldn't be impacted if those URIs were used and the same container change was involved. The main difference is that for default usage it shouldn't *need* any of those URIs, while V2 pretty much relies on them to work as intended.

I myself have V3 running with plenty of old config files with those URIs in them, but I don't run Tomcat, or it would be easy to tell.

Anway, I would suggest somebody file a bug on it. It will be very difficult for us to find the time to explore this deeply for V2, but I think an initial focus would be to determine how much impact there is on V3 if any.

-- Scott

More information about the users mailing list