Validation Warning in tomcat 7(.69) startup

[Colin Hilbert]

I have an idp.war that I am trying to deploy on tomcat. I get a warning from spring framework in the startup logs.

Failed to read schema document 'class path:/schema/shibboleth-2.0-services.xsd'

the trace immediately after complains about a line in a /WEB-INF/conf/service.xml is invalid.

Nested exception: Cannot find the declaration of element 'src:Services'.

What should I do to further debug this?

in my Service.xml I have
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
and
xsi:schemaLocation="urn:mace:shibboleth:2.0:services classpath:/schema/shibboleth-2.0-services.xsd
(along with many others listed after)
going exactly to that location:
http://www.w3.org/2001/XMLSchema-instance/schema/shibboleth-2.0-services.xsd
brings me to a w3 page but it says document not found. Am I not checking on that correctly? This war doesn't get this error when deployed on tomcat 7 (.55)

[Tim Holloway]

The difference between a URN (Uniform Resource Name) and a URL (Uniform Resource Locator) is that - in theory, a URL can be sent out from an HTTP client to retrieve a resource, whereas a URN is merely an identifier.

What your xsi schemaLocation does is map a URN to a URL so that the symbolic name associated with the logical namespace can be used to retrieve the actual XSD.

Since your associated URL is "classpath:/schema/shibboleth-2.0-services.xsd", I'd expect to find a directory named "/WEB-INF/classes/schema" in the WAR and a file named shibboleth-2.0-services.xsd within that directory. Or, alternatively, one of the libraries within WEB-INF/lib would contain a directory named "/schema" which contained shibboleth-2.0-services.xsd.

The message you're getting implies that neither of the above situations exist.

[Colin Hilbert]

Tim Holloway wrote:The difference between a URN (Uniform Resource Name) and a URL (Uniform Resource Locator) is that - in theory, a URL can be sent out from an HTTP client to retrieve a resource, whereas a URN is merely an identifier.

What your xsi schemaLocation does is map a URN to a URL so that the symbolic name associated with the logical namespace can be used to retrieve the actual XSD.

Since your associated URL is "classpath:/schema/shibboleth-2.0-services.xsd", I'd expect to find a directory named "/WEB-INF/classes/schema" in the WAR and a file named shibboleth-2.0-services.xsd within that directory. Or, alternatively, one of the libraries within WEB-INF/lib would contain a directory named "/schema" which contained shibboleth-2.0-services.xsd.

The message you're getting implies that neither of the above situations exist.

I've grep'd for xsd in my idp deployment inside WEB-INF/lib and found shibboleth-common-1.2.1.jar has that resource xsd in the path /schema/shibboleth-2.0-resource.xsd

I also have grep'd for srv in tomcat's lib folder and found the jar ecj-4.4.2.jar has srv in it. So both things exist.

Do you think it is an issue with tomcat not using ecj to define srv:Services first before trying to use it in Services.xml?

I see the default class loader order is:

Bootstrap classes of your JVM
/WEB-INF/classes of your web application
/WEB-INF/lib/*.jar of your web application
System class loader classes (described above)
Common class loader classes (described above)

and that ecj jar is one of the common class loader classes as described here:

https://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html

I also see a mention of a setting:

<Loader delegate="true"/>

which will set the order to:

Bootstrap classes of your JVM
System class loader classes (described above)
Common class loader classes (described above)
/WEB-INF/classes of your web application
/WEB-INF/lib/*.jar of your web application

but I don't see where it says to put this setting.

Update I found where to put the setting. Context.xml. But it changes nothing about the error message.

I guess the failure in reading the .xsd shibboleth document causes the Context initialization and not the other way around. That was confusing me for a bit there.

So the exception states it gets hung up on reading even the first file in that list but I can look in that jar and see them there. All of them. in that /schema/ path

Update 2 The first stack gives a short list of reasons why it could have failed:

1) could not find the document.
2) the document could not be read.
3) the root element of the document is not <xsd:schema>

for that #3: When I open the shibboleth-2.0-services.xsd should the root element actually be

<xsd:schema ... >

or is it ok for it to be just

<schema ... >

?

[Colin Hilbert]

If I move all of the jars from idp/WEB-INF/lib/ to apache-tomcat-7.0.69/lib/

it gets past the error

but then I get a different one saying Error loading logging configuration file: /Users/<me>/Development/apache_classpath_issue/apache-tomcat-7.0.69/bin/@webapp.root@/WEB-INF/conf/logging.xml

of course it wont find the logging.xml file there because it's actually in apache-tomcat-7.0.69/webapps/idp/WEB-INF/conf/

so for one it isn't pulling in the value of @webapp.root@ and even if it did, I don't think it could get to it from /bin/

I rechecked the issue with the jars as well with different versions and I don't have the jar issue in tomcat 7.0.65, I was going to check the next release .67, but I think that was when I first saw it happen.

[Colin Hilbert]

I have since joined the tomcat user support emailing list and one of the tomcat folks think the issue has come from this fix:

https://bz.apache.org/bugzilla/show_bug.cgi?id=56777

They are checking into it.

[Tim Holloway]

Sorry, I lost this thread.

Don't EVER move jars from a WAR to TOMCAT_HOME/lib. Unless the jars were specifically designed to be shared along multiple classpaths (for example, the JDBC driver jars), you can really wreck your entire Tomcat server.

You've got a lot of details in your recent report that I haven't had time to look at closely, but if you're setting up Spring Boot to run Tomcat, I'd recommend that you put the Context definition into the WAR's META-INF/context.xml file.

In fact, if you're running Spring Boot, I would keep the Tomcat config customizations themselves to a minimum, especially if you're not familiar with the ins and outs of embedded Tomcat. Otherwise they might not get picked up and used (or at least used properly).

Final note: Tomcat doesn't have a single classpath. It has multiple classpaths. Every deployed webapp has a unique classpath (it's how Tomcat keeps webapps from leaking over onto each other), Tomcat's main task has a classpath, various other resources will have classpaths of their own.