• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Bear Bibeault
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • salvin francis
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
Bartenders:
  • Jj Roberts
  • Carey Brown
  • Scott Selikoff

Validation Warning in tomcat 7(.69) startup

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
 
Saloon Keeper
Posts: 23280
158
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 or is it ok for it to be just ?
 
Colin Hilbert
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 23280
158
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic