Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 11/30/12 10:11 AM, André Warnier wrote:
Jeffrey Janner wrote:
-----Original Message----- From: Paul van Hoven
[mailto:paul.van.ho...@googlemail.com] Sent: Wednesday,
November 28, 2012 5:29 PM To: Tomcat Users List Subject: Re:
Tomcat with multiple domains
Hi!
Thanks for your quick and detailed answers. Actually I think I
did all the things you mentioned but it still does not work. So
here are the changes I made:
1. I checked that the following entries are in the engine tag:
<Server port="8005" shutdown="SHUTDOWN"> ... <Service
name="Catalina"> ... <Engine name="Catalina"
defaultHost="localhost"> <Host name="localhost"
appBase="webapps" unpackWARs="true" autoDeploy="true">
[Jeff Janner] You need a "</Host>" here. All elements must have
a begin tag and an end tag! If there are no sub-elements, you can
combine the begin and end tags as <tagname ... />. Please find a
good introductory reference on XML markup language before
continuing.
<Host name="www.my2nddomain.com"
appBase="/opt/apache-tomcat-7.0.32/my2nddomain"
unpackWARs="true" autoDeploy="true" xmlValidation="false"
xmlNamespaceAware="false"> </Host>
Haaa. Good catch, Jeffrey. Everyone else missed that.
+1
So it probably "swallowed" the second Host's tags in the first,
with who knows which results. Surprising that Tomcat still starts.
Unfortunately, Tomcat does not validate against an XML schema or DTD
and so otherwise insane configurations can generally be launched
without any errors being generated.
This is a double-edged sword. In this case, it made it difficult to
detect a configuration error. In other cases, it makes it possible to
use very complex configuration that the Tomcat developers didn't
expect beforehand.
One reason Tomcat cannot validate against a schema or DTD is because
of things like <Resource>: they allow a user to specify any attribute
name and have its value get set on the component being configured.
This is not possible with a strictly-validating parser.
I'm unaware of a technique to allow partial structural validity (say,
element nesting) without also explicitly specifying which attributes
are allowed.
Use of the Apache commons-digester component means that detecting
structural missteps would require that the component be configured
with all possible missteps in advance which is quite impossible.
I haven't looked, but it might be nice if the digester supported
fallback rules where an event that didn't match an existing rule could
fire a catch-all rule. That way, an unexpected element could generate
an error message and possibly prevent Tomcat from even starting.
I wasn't complaining or criticising, just wondering.
It isn't so easy to compose an XML document, miss a closing tag and still having it be
valid XML.
If you go back the the OP's last post and the described symptoms, and assume that he did
describe accurately what happened, it means that the missing </Host> tag had some really
interesting effects.
What we really need on this user list, is an interactive XML parser where we can check
configuration snippets posted by users.
(one which would of course first and automatically get rid of all the email artifacts,
in-between comments etc.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org