Yes - I know. Wrote the email when I was borderline homicidal maniac after trying to work out why Xerces 2 doesn't like the same documents that Xerces 1 is more than happy with. I'm not thick (not a genius either!) - you don't get 82% on an AI assignment without having a few brain cells - but XML...
-----Original Message----- From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]] Sent: 19 March 2002 22:49 To: Tomcat Users List Subject: RE: XML curiosities The reason xml is so popular is that it is ubiquitous. At 07:33 PM 3/19/02 +0000, you wrote: >Adam, > >I'm not entirely certain why XML is so popular. XML tools are thin on the >ground, as is any decipherable information. The spec's make little sense - >borderline gibberish. I've tried making the XML files you refer to more >"well formed" but all I get is more errors! I've tried using references of >the nature "http://somesite"; rather than URI's that are absolute or system >dependant - more errors. Does my head in - I'll stick to theoretical physics >:) > >The setup with LUSID (a servlet) is that there are a series of .ent files >containing entity reference. Each entity file might also use other entity >files. The xml documents that LUSID uses, use the DTD and the entity files. >I've not found *anywhere* where it says that this is "valid" or possible. It >does work with Xerces 1 but not 2. > >Thanks, > >John > > >-----Original Message----- >From: Dr A.C. Marshall [mailto:[EMAIL PROTECTED]] >Sent: 19 March 2002 17:33 >To: John Wadkin >Cc: Tomcat Users List (E-mail) >Subject: Re: XML curiosities > > >Funnily enough (as it always is!) - we've been having problems with a >new version of xerces on the WBL project that I supervise. It just keeps >coming back with things that arent wrong - for example, it claims an >entity isnt defined when it quite plainly is (and the other entities in >the same file are OK, and also theres an attempt to load local.ent by >uising a relative path not an absolute**. the relative path is something >like > > "../../../../../../../../ents/lusid.ent" > >the parser claims that the file > > /lusid/uk/ac/liv/pages/test/../../ents/lusid.ent > >doesnt exist - well I know it doesnt thats why the path is pointing else >where - it just seems to ignore the first part of the path. Got no idea >at all what is going on - it works fine with abs paths - can the parser >be full of bugs? > >What is the line which is supposed to be causing problems in cqdefs? > >Adam > >** that reminds me the liverpool page tree that I sent had absolute >paths to the ents files so they wont be found on your server - sorry! >On Tue, 19 Mar 2002, John Wadkin wrote: > >|All, >| >|A few XML issues. Firstly, I wrongly put this in server.xml: >| >|<Valve classname="org.apache.catalina.valves.RemoteAddrValve" >| allow="<ip address>, <ip address>" /> >| >|Instead of seeing a SAX parse exception or similar, this appeared in >|catalina.out: >| >|ERROR reading /usr/local/tomcat/conf/server.xml >|At Line 29 /Server/Service/Engine/Host/Context/Valve/ >|classname=org.apache.catalina.valves.RemoteAddrValve allow=161.112.*, >|194.164.* >| >|Catalina.start: java.lang.NullPointerException >|java.lang.NullPointerException >| at java.lang.Class.forName0(Native Method) >| at java.lang.Class.forName0(Compiled Code) >| at java.lang.Class.forName(Compiled Code) >| at org.apache.catalina.util.xml.ObjectCreate.start(Compiled Code) >| at org.apache.catalina.util.xml.XmlMapper.matchStart(Compiled Code) >| at >|org.apache.catalina.util.xml.XmlMapper.startElement(XmlMapper.java:91) >| at org.xml.sax.helpers.XMLReaderAdapter.startElement(Compiled Code) >| at org.apache.xerces.parsers.SAXParser.startElement(Compiled Code) >| at >|org.apache.xerces.validators.common.XMLValidator.callStartElement(Compiled >|Code) >| at >|org.apache.xerces.framework.XMLDocumentScanner.scanElement(Compiled Code) >| at >|org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch( C >o >|mpiled Code) >| at org.apache.xerces.framework.XMLDocumentScanner.parseSome(Compiled >|Code) >| at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081) >| at >|org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223) >| at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) >| at javax.xml.parsers.SAXParser.parse(SAXParser.java:290) >| at >|org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228) >| at org.apache.catalina.startup.Catalina.start(Catalina.java:725) >| at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) >| at org.apache.catalina.startup.Catalina.process(Catalina.java:179) >| at java.lang.reflect.Method.invoke(Native Method) >| at java.lang.reflect.Method.invoke(Compiled Code) >| at org.apache.catalina.startup.Bootstrap.main(Compiled Code) >| >|Is this behaviour correct? It's very misleading - took me a while to work >|out what was wrong! >| >|Secondly, I changed the parser in common/lib to Xerces 2 - the two jar >|files. I expected TomCat to break, but it worked fine. However, the new >|parser reported that an XML document wasn't well-formed. I didn't think >|upgrading a parser would change the "status" of an XML document from "OK" >to >|"not OK"! What gives? Is the latest version of Xerces more strict? >| >|Solaris 8 >|Tomcat 4.0.1 >|Apache 1.3 >|mod_webapp 1 >| >|Thanks, >| >|John >| > >-- > Dr AC Marshall ([EMAIL PROTECTED]). LUSID System Programmer, > Centre for Lifelong Learning, University of Liverpool. > > Cheese of the Millenium: Quejo con Piri Piri > >This email and any files transmitted with it are confidential and intended >solely for the use of the individual or entity to whom they are addressed. > >-- >To unsubscribe: <mailto:[EMAIL PROTECTED]> >For additional commands: <mailto:[EMAIL PROTECTED]> >Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
