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

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]
> >
>