Fw: [resolver] - XCatalog support not functional in resolver package

(forwarding to commons-dev)

Jacob,

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?

Thanks.

[1] http://issues.apache.org/bugzilla/enter_bug.cgi
[2] 
http://www.oasis-open.org/committees/download.php/14041/xml-catalogs.html

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]

Jacob Kjome <[email protected]> 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 
with 
> that move, I lose native Xerces1 support for XCatalogs.  I realize it's 
the 
> 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 
why.Enjoy!...
> 
> 1.  When registered via SAXCatalogReader.setCatalogParser(String, 
String, 
> String), the XCatalogReader will never be successfully instantiated via 
> Class.forName() because it doesn't have a default constructor.  You 
might 
> also notice that this is the default way that Catalog.setupReaders() is 
> implemented.  OASISXMLCatalogReader has a default constructor and 
doesn't 
> 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 
in 
> 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 
rootElement 
> 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 
the 
> parser is being initialized for the first time, it looks up the parser 
via 
> 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 
will 
> 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 
the 
> 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, 
it 
> was supported by Apache in Xerces1.  Except the DTD supplied there 
defines 
> "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 
the 
> xcatalog.dtd for proof of this...
> 
> http://xerces.apache.org/xerces-
> j/apiDocs/org/apache/xerces/readers/XCatalog.html
> 
> http://svn.apache.org/viewcvs.
> 
cgi/xerces/java/branches/xerces_j_1/src/org/apache/xerces/readers/xcatalog.
> 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 
to 
> 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 
my 
> 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 
line 
> 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 
pain 
> 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 
seem 
> to help?  Maybe someone else can say?
> 
> 
> So..... I guess the question is, did anyone actually test the 
functionality 
> 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 
to 
> be shipping in not too long, and it would be ever so nice if 
resolver.jar 
> contained an XCatalogReader actually worked as advertised.  Please 
forgive 
> 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 
in 
> mapping out how to fix the existing problems.
> 
> thanks!
> 
> Jake
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>