xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: Fw: [resolver] - XCatalog support not functional in resolver package
Date Wed, 08 Feb 2006 05:29:42 GMT

Hi Michael,

I've supplied a patch for Resolver XCatalog support as well as a minor (but 
important) change to Xerces.  See the following reported issues (with 
patches attached)....



I would be grateful if you would push for committing of the resolver 
patch.  And the Xerces2 patch is so minor, it shouldn't even need 
testing.  Both are of great importance if I am going to move XMLC from 
Xerces1 to Xerces2.



At 10:50 AM 2/2/2006 -0500, Michael Glavassevich wrote:
 >(forwarding to commons-dev)
 >Probably the best way to get the problems you've listed addressed would be
 >to submit patches for them in Bugzilla [1] and then get the attention of
 >one of the developers to review and commit them. If there were to be a
 >resolver release this month, we would include it in Xerces-J 2.8.0. I
 >haven't followed its development for awhile so I'm not sure what state the
 >resolver is in though I seem to recall some work being done for XML
 >Catalogs 1.1 [2] last year. Anyone know what the status is?
 >[1] http://issues.apache.org/bugzilla/enter_bug.cgi
 >Michael Glavassevich
 >XML Parser Development
 >IBM Toronto Lab
 >E-mail: mrglavas@ca.ibm.com
 >E-mail: mrglavas@apache.org
 >Jacob Kjome <hoju@visi.com> wrote on 01/31/2006 01:57:24 AM:
 >> Hello,
 >> I'm making an attempt to update XMLC ( http://xmlc.enhydra.org/ ) to
 >> Xerces2 from Xerces (XMLC has dependencies on the Xerces1 implementation
 >> classes for various valid reasons that I won't go into here).  Along
 >> that move, I lose native Xerces1 support for XCatalogs.  I realize it's
 >> old catalog format, but it's been that way forever and XMLC needs to
 >> continue to support it.  However, as I've found out, XCatalog support in
 >> the resolver package is less than useful.  Here's a few reasons
 >> 1.  When registered via SAXCatalogReader.setCatalogParser(String,
 >> String), the XCatalogReader will never be successfully instantiated via
 >> Class.forName() because it doesn't have a default constructor.  You
 >> also notice that this is the default way that Catalog.setupReaders() is
 >> implemented.  OASISXMLCatalogReader has a default constructor and
 >> suffer from this problem.
 >> 2.  Even if XCatalogReader had a default constructor so it could be
 >> successfully instantiated via reflection, it would fail to be found as a
 >> registered catalog parser because of a bad assumption.  In
 >> Catalog.setupReaders(), the XCatalog parser is setup like this...
 >> saxReader.setCatalogParser(null, "XMLCatalog",
 >>                 "org.apache.xml.resolver.readers.XCatalogReader");
 >> Notice that null is passed for the namespaceURI.  Now, here's the method
 >> SAXCatalogReader...
 >> public void setCatalogParser(String namespaceURI,
 >>                 String rootElement,
 >>                 String parserClass) {
 >>      if (namespaceURI == null) {
 >>        namespaceMap.put(rootElement, parserClass);
 >>      } else {
 >>        namespaceMap.put("{"+namespaceURI+"}"+rootElement, parserClass);
 >>      }
 >>    }
 >> So, when null is passed as the namespaceURI, it uses only the
 >> as the key in the Map.  The corresponding logic is done in
 >> getCatalogParser(String, String).  So far, so good.  However, in
 >> SAXCatalogParser.startElement(String, String, String, Attributes), when
 >> parser is being initialized for the first time, it looks up the parser
 >> getCatalogParser(String, String) always passing a non-null namespaceURI
 >> argument (I guess because the XML parser uses an empty string instead of
 >> null for a missing namespaceURI?).  So, the assumption made in
 >> set/getCatalogParser() falls flat on its face for XCatalogReader.  It
 >> never be found because it was registered in the map with the key
 >> "XMLCatalog", but when it is looked up, it will always attempt to use
 >> key "{}XMLCatalog", which will never exist.
 >> 3.  Now lets say both 1 and 2 are fixed.  Well, XCatalogReader assumes a
 >> root element of "XMLCatalog".  The javadoc says it supports the "XML
 >> Catalog format developed by John Cowan and supported by Apache".  Well,
 >> was supported by Apache in Xerces1.  Except the DTD supplied there
 >> "XCatalog" as the root element, not "XMLCatalog".  This is not good for
 >> users of that DTD since the document will never validate against what
 >> XCatalogReader expects.  See the Xerces1 javadoc for XCatalog.java and
 >> xcatalog.dtd for proof of this...
 >> http://xerces.apache.org/xerces-
 >> j/apiDocs/org/apache/xerces/readers/XCatalog.html
 >> http://svn.apache.org/viewcvs.
 >> dtd?rev=317487&view=markup
 >> 4.  Let's say that 1 and 2 are a lost cause and we'll just ignore 3 by
 >> changing our root element to "XMLCatalog" in the XML and update the DTD
 >> match this... or just stop referencing the DTD altogether to get around
 >> this problem (BTW, this is not an option for XMLC.  It needs to be
 >> "XCatalog" so that it matches the DTD which, it seems to me, ought to be
 >> distributed with resolver.jar just like the other catalog dtd, no?).  We
 >> just instantiate XCatalogReader directly and add it to the Catalog
 >> ourselves....
 >> catalog.addReader("application/xml", new XCatalogReader(spf));
 >> Then, we try it out.  Low and behold, it bombs out with a
 >> NullPointerException in startElement(String, String, String, Attributes)
 >> after parsing the first child entry of the root "XMLCatalog" element in
 >> catalog, which is "Map" (I know this by subclassing XCatalogReader and
 >> implementing startElement(), doing some debugging, and then passing on
 >> execution to super.startElement()).  I'm not 100% sure exactly which
 >> it blows chunks on because the classes in resovler.jar, distributed with
 >> Xerces-2.7.1, didn't have have debug enabled when compiling (does the
 >> ever stop?), but it is somewhere in here...
 >> } else if (localName.equals("Map")) {
 >>        entryType = catalog.PUBLIC;
 >>        entryArgs.add(atts.getValue("PublicId"));
 >>        entryArgs.add(atts.getValue("HRef"));
 >>        catalog.getCatalogManager().debug.message(4, "Map",
 >>           PublicId.normalize(atts.getValue("PublicId")),
 >>           atts.getValue("HRef"));
 >> } else ....
 >> I suspect that the catalog is null for some reason, although I tried to
 >> hack it up and set the catalog in my implementation of startElement()
 >> before passing on execution to super.startElement(), but that didn't
 >> to help?  Maybe someone else can say?
 >> So..... I guess the question is, did anyone actually test the
 >> of XCatalogReader?  I'll take a wild guess at the
 >> answer.  No!  Why?  Because it's quite simply impossible for it to have
 >> passed any test, as I've shown above.
 >> Will this be fixed in the next release?  I think Xerces-2.8.0 is going
 >> be shipping in not too long, and it would be ever so nice if
 >> contained an XCatalogReader actually worked as advertised.  Please
 >> the sharp tongue.  I tried to keep things relatively lighthearted, but I
 >> also wanted to convey a hint of bitterness after attempting, on and off,
 >> for a full day to get this to work, finally figuring out all the issues
 >> that I detailed above.  In any case, I hope my descriptions are useful
 >> mapping out how to fix the existing problems.
 >> thanks!
 >> Jake
 >> ---------------------------------------------------------------------
 >> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
 >> For additional commands, e-mail: general-help@xml.apache.org

View raw message