Quoting Michael Glavassevich <[EMAIL PROTECTED]>: > (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: [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] > > >
