From commons-dev-return-586-apmail-xml-commons-dev-archive=xml.apache.org@xml.apache.org Fri Feb 03 13:29:37 2006 Return-Path: Delivered-To: apmail-xml-commons-dev-archive@www.apache.org Received: (qmail 79518 invoked from network); 3 Feb 2006 13:29:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Feb 2006 13:29:36 -0000 Received: (qmail 9521 invoked by uid 500); 3 Feb 2006 13:29:36 -0000 Delivered-To: apmail-xml-commons-dev-archive@xml.apache.org Received: (qmail 9405 invoked by uid 500); 3 Feb 2006 13:29:35 -0000 Mailing-List: contact commons-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list commons-dev@xml.apache.org Delivered-To: moderator for commons-dev@xml.apache.org Received: (qmail 9429 invoked by uid 99); 2 Feb 2006 23:00:10 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of hoju@visi.com designates 208.42.156.2 as permitted sender) Message-ID: <1138921188.43e28ee4161b0@my.visi.com> Date: Thu, 2 Feb 2006 16:59:48 -0600 From: Jacob Kjome To: commons-dev@xml.apache.org Subject: Re: Fw: [resolver] - XCatalog support not functional in resolver package References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 162.136.192.1 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Quoting Michael Glavassevich : > (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. I was hoping to find at least a little bit of developer interest. When I find out that code I wrote doesn't work properly, I usually get on the ball and fix it. I don't see that happening so far. I might have to resort to fixing it myself and providing the patches. > If there were to be a > resolver release this month, we would include it in Xerces-J 2.8.0. I could try to get it done in the next couple of weeks. There's also a couple of issues in the Xerces2 code that I might provide patches for as well, such as in the HTML DOM where there are a couple cases where constructors are package private and I need them public so that a couple custom DOM's in XMLC can extend them. I'll provide details (patches) later. Jake > 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: mrglavas@ca.ibm.com > E-mail: mrglavas@apache.org > > Jacob Kjome 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: general-unsubscribe@xml.apache.org > > For additional commands, e-mail: general-help@xml.apache.org > > >