DO NOT REPLY [Bug 43761] New: - sub catalogs not resolving public identifiers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43761>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43761

           Summary: sub catalogs not resolving public identifiers
           Product: XmlCommons
           Version: 1.x
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: regression
          Priority: P2
         Component: Resolver
        AssignedTo: [email protected]
        ReportedBy: [email protected]


I have a catalog that refer to another catalog using CATALOG catalog2

If I try to call resolvePublic on an identifier that is in catalog2 I get a 
catalog file not found problem.

This didn't happen with 1.1, but appears in 1.2

I tracked it down to Catalog.java, parseCatalogFile method. When it is lazy 
loading the catalogs, it generates base, but the fileName may already be a 
file: reference, so it ends up creating file:/foo/file:/foo/catalog, which 
can't be found.

I have fixed it locally by changing
            base = new URL(catalogCwd, fixSlashes(fileName));
to 
        // this catalog may have been pointed to by another, so we need to 
check if it already
        // has the base prepended            
        if (!fileName.startsWith("file:")) {
            base = new URL(catalogCwd, fixSlashes(fileName));
        } else {
            base = new URL(fixSlashes(fileName));
        }
but I suspect that that isn't a very clean way of doing it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.