xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Smith <brian-l-sm...@uiowa.edu>
Subject Re: New resolver all checked in
Date Tue, 17 Dec 2002 04:12:41 GMT
David Crossley wrote:
> Norman Walsh wrote: 
> 
>>Ok, I've checked in a whole raft of changes to the resolver code. I
>>don't think I've broken anything, and I have some new tests under
>>tests/resolver that demonstrate that my new code works (at least for
>>me :-)
>>
>>I'd appreciate feedback from anyone who can give it a whirl.
>>
>>Release notes:
> 
> <snip/>
> 
> I tried the new resolver with Apache Cocoon head 2.1-dev
> No problems for me on Linux. I will add it to the cocoon cvs
> and we will see what happens for others.
> 
> It only needed some minor changes to our code to
> use setVerbosity() instead of Debug.setDebug()
> 
> However we are only using resolver very basically
> with o.a.x.resolver.tools.CatalogResolver
> It suits us fine. Thanks
> 
> --David

I agree with David, I've not noticed any major problems. The only minor 
things I've seen are:

(a) the library defaults to logging things to the system console, and so 
at least one message ("Cannot find CatalogManager.properties") will be 
printed to the system console no matter what, unless a system property 
is set. IMO, the defaults for the resolver library should allow a client 
to use the resolver without setting any system properties and without 
getting any output to System.err/System.out.

(b) The resolver library does not have any special support for resolving 
the public ID for the DTD for XML catalogs. Thus, if you don't put that 
DTD in your local personal system-wide catalog, the catalog resolver 
will attempt to retrieve the DTD from the OASIS website. Again, it is 
seems very difficult to override this in a client application. Probably 
the resolver library should include the OASIS XML Catalog DTD inside its 
own JAR file and resolve this public ID specially.

I am using the resolver inside two ant tasks I have written, which is 
why I'm trying to avoid:
    * spurious network connections (issue (b) above)
    * requiring users to have any entries in their local catalogs
      (issue (b))
    * setting any system properties (issue (a)).

But, none of this affects me in a serious manner, it is more of a "It 
would be nice if it worked like that" kind of thing.

- Brian


Mime
View raw message