DO NOT REPLY [Bug 45210] New: Base systemId not set when parsing XML catalogs

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210

           Summary: Base systemId not set when parsing XML catalogs
           Product: XmlCommons
           Version: 1.x
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Resolver
        AssignedTo: commons-dev@...
        ReportedBy: earl@...


Created an attachment (id=22130)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22130)
Patch to specify systemId for catalog intput source

The systemId of the XML input source of a catalog file
is not set when calling SAX parser.  This causes any
relative external references in the file to resolve
against the incorrect base (current working dir) versus the
correct base (location of catalog file).

This problem normally leads to a fatal exception by
the SAX parser since the external entity cannot be found.

Attached is a patch that supports setting the systemId of
the catalog input source so relative external entities
will be resolved against the proper base.

NOTE: The classes DOMCatalogReader and TextCatalogReader
currently have stubs for systemId support: they just call
base readCatalog() method w/o systemId support.  Unsure
if these classes are even used in practice.


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

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210





--- Comment #1 from David Crossley <crossley@...>  2008-06-24 22:07:23 PST ---
Have you considered the effect of the "relative-catalogs" property?
http://xml.apache.org/commons/components/resolver/tips.html
http://xml.apache.org/commons/components/resolver/resolver-article.html


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

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210


David Crossley <crossley@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




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

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210


David Crossley <crossley@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #2 from David Crossley <crossley@...>  2008-06-25 01:23:20 PST ---
(Woops, accidently closed this when Bz skipped to the next issue.)


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

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210


Earl Hood <earl@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |earl@...




--- Comment #3 from Earl Hood <earl@...>  2008-06-26 07:51:05 PST ---
Are you stating the patch breaks some existing behavior?
This fixes a problem with the actual parsing of catalog
files via the SAX parser.

In the project I'm working on, the resolver errors out
on XML catalog files that have doctype declarations.  For example:

  <!DOCTYPE catalog SYSTEM "../../../dtd/catalog.dtd>
  <catalog>...

The problem is the resolver does not set the initial base
URI when calling SAX.  Therefore, the *SAX parser* will
resolve all (XML) entities with a base URI of the current working
directory, and NOT the location of the catalog file.

Therefore, in the above, the URI "../../../dtd/catalog.dtd"
will be looked up by the SAX parser based on the current
working directory.  But, the URI should be resolved based
on the location of the catalog file.

The patch basically sets the systemId setting when SAX is
invoked when parsing the file so any relative URI *entity*
references in the catalog itself will be resolved against
the correct base.

None of this affects how catalog paths are resolved via
things like <nextCatalog> entries since that is an
application-specific processing task and not something the
SAX parser resolves itself.


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

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210





--- Comment #4 from David Crossley <crossley@...>  2008-07-18 02:44:27 PST ---
I have not tried the patch yet, and now away for another week.

When you talked about relative references, i thought that you were referring to
entries within the catalog. See one of our examples at:
[1]
http://svn.apache.org/repos/asf/forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat
The "uri" attributes of the "public" elements do get resolved relative to the
catalog.forrest.xcat file.

Anyway, now i see that you mean the DTD for the catalog itself.

By the way, i think that i am still a bit confused by that "relative-catalogs"
property and will attempt again to understand the docs.

Note that we use a PublicIdentifier for our catalogs (e.g. [1] above). IIRC the
Resolver handles this internally when we do it that way. We don't need the
catalog.dtd to be present, and it doesn't bang on the net to try to get it from
that SystemIdentifier URL.

I will still investigate your patch and do some testing.


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