xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Walsh <...@nwalsh.com>
Subject Re: Resolver Library and Ant Task
Date Wed, 13 Nov 2002 13:48:56 GMT
Hash: SHA1

/ Brian Smith <brian-l-smith@uiowa.edu> was heard to say:
| (1) The CatalogResolver repeatedly prints out "Cannot find
| CatalogManager.properties" even when I am using a private catalog. It
| seems that the only way to shut this warning off is to set a system
| property or include a catalog.properties file in the classpath. I
| don't think that either of these things is a good thing for an Ant
| task to do. I need some way to tell the Catalog library not to output
| any messages, not to use any system catalogs, etc. without setting any
| system properties, etc.

The 1.1 release will have a more flexible catalog manager system.
In the meantime, if you set the system property xml.catalog.ignoreMissing
to any non-null value, the messages should stop.

| (2) In general, it would be very good if the library worked in such a
| way that the system properties/catalogs were only used if they were
| explicitly designated to be used. For example, it seems like there
| could be a single instance of Catalog that represents all the system
| catalog files, and any application that wants to use the system
| catalog files would create the proper entry in their own catalog that
| delegates to this (shared) system catalog. For example (see below too):
|       ResolvingXMLReader reader = new ResolvingXMLReader();
|       // The reader's catalog is empty
|       reader.getCatalog().addCatalog(Catalog.getSystemCatalog());
|       // Now the reader has access to the system catalog

There is already a static catalog that uses all the system properties.
If you don't go to some lengths to avoid it, that's what you get.
As for "falling back" to the system catalogs,

| (3) I have found that I would like to have an instance of Catalog
| delegate to another instance of Catalog. Currently, this doesn't seem
| to be possible without subclassing. The idea is to group sets of
| catalogs together in different configurations, such that each catalog
| file is only read once, like this:
|      Catalog a = new Catalog();
|      a.parseCatalog(someFile);
|      a.parseCatalog(someOtherFile);
|      Catalog b = new Catalog();
|      b.parseCatalog(yetAnotherFile);
|      b.addCatalog(a);  // b will now delegate to a as ncessary

I think something like this is probably the right answer. I'll look into it.

| (4) CatalogResolver works fine, but you have to be careful when using
| the document() function in XSLT. The XSLT engine isn't guarenteed to
| use the same entity resolver that it uses for the main document. I had
| to subclass it like this:
| final XMLReader reader = XMLReaderFactory.createXMLReader();
| CatalogResolver resolver = new CatalogResolver(true) {
|      public Source resolve(String base, String href)
|          throws TransformerException {
|          SAXSource result = (SAXSource) super.resolve(base, href);
|          result.setXMLReader(reader);
|          return result;
|      }
| }
| In other words, I make sure that all documents use the same XMLReader
| so that they will use the same EntityResolver.

I seem to avoid this problem by using org.apache.xml.resolver.tools.ResolvingXMLReader
as my XMLReader class. Is that solution inappropriate for your application?

                                        Be seeing you,

- -- 
Norman.Walsh@Sun.COM    | All professional men are handicapped by not
XML Standards Architect | being allowed to ignore things which are
Web Tech. and Standards | useless.--Goethe
Sun Microsystems, Inc.  | 
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>


View raw message