Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: RE: Possible Entity Resolving Bug
From: David Crossley <crossley@indexgeo.com.au>
To: cocoon-dev@xml.apache.org
In-Reply-To: <BGEHKCAMFOJCLOMCEPJECEKFFHAA.jeremyaston@yahoo.co.uk>
References: <BGEHKCAMFOJCLOMCEPJECEKFFHAA.jeremyaston@yahoo.co.uk>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 13 Sep 2002 18:20:14 +1000
Message-Id: <1031905216.1771.2131.camel@ighp>
Mime-Version: 1.0

Jeremy Aston wrote:
>
> Thanks for the response.  I'm glad it's not just me and my ever expanding
> understanding of entity catalogs that have gone loopy!  For the sake of
> brevity I'm cutting the previous stuff and just responding to this bit....
>
> >> This does not appear to be a fundamental catalog problem.  I modified the
> >> entity catalog tests to test the above scenarios and everything worked.
> 
> David Crossley wrote:
> >I am not sure what you mean here. Are you saying that you
> >can get the SystemId resolved via "./build.sh test" whereas
> >it will not work via "./build.sh docs"?
> 
> Basically I modified the ResolverImplTestCase class to add in some tests
> that would establish if a system id could be resolved if there was no public
> id passed along with it.  The two existing test cases just test for
> available and non available entities and both supply a public id.  My tests
> check a HTTP, URN and file URIs, each of them having a match in the catalog
> to the same s.o.i.  None of the tests supply a public id.  As an example:
> 
<snip good test-case example/>
> 
> The catalog entry (in the test class) for this is:
> 
> "SYSTEM \"urn:x-pigbite:person\"                  \"person.dtd\"\n" +
> 
> Add in the dtd to the test folder, run build test and everything works fine.
> What this is proving that IF you call (for example) resolveEntity( null,
> "urn:x-pigbite:person" ); then this can be resolved OK.  A simple bit of
> debug in ResolverImpl.resolveEntity() method proves that when attempting to
> resolve a DOCTYPE SYSTEM identifer it is ALWAYS passed as null (regardless
> of if a public id exists or not), yet when using a system identifier with
> ENTITY it will get passed through and this can be resolved.
> 
> My feeling is that the xml-commons code is fine (the tests prove it), they
> are simply getting passed incorrect data.  Question is, is this Cocoon or
> parser specific?  I am more than happy to chase this down, so - if you
> concur - I will raise a bug and get on to it.

Please do. It would be grand if you could also add a patch
to get your additional test cases into CVS. Cocoon is
generally lacking in that area.

> I have not noticed any problems running build docs but you have made me
> curious as to if there are any issues there!

You do not see problems there because nothing in the
build docs will exercise the bug. Try changing the
document type declaration on one of the xdocs instances
to use a systemID and it will break. That is how i
tested your hypothesis.

> Do you have anything in mind
> that might be wrong?

No. Let us start with your new test cases and then see
what is different to ResolverImpl.java

Aha. I just checked Xerces-J release notes and found
something relevant.
http://xml.apache.org/xerces2-j/releases.html
----
2.0.1
Fixed an entity resolution bug: we passed null as the
system ID to the entity resolver.  [Sandy Gao]
----

I see that Cocoon-2.0.3 (your bug-report branch) is
still using Xerces-2.0.0

I have not yet had time to try Cocoon-2.1 to see if
this same issue exists there. I do see that Carsten
upgraded head CVS to Xerces-2.1 last week, so perhaps
the bug is gone there.

> If I remember correctly, docs is the only bit where
> validation is forced...

It used to do validation. Unfortunately we had to
switch it off due to an obscure bug ...
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6200
Parser failure with validate=true when processing stylesheet

> Thanks for the xml-commons pointers btw - in the process of doing this
> searching I cottoned on to that earlier this weekend so if it looks like the
> scope is moving outside of Cocoon then Mr Walsh et al will be hearing from
> me ;-).

We should first explore the Cocoon situation. Unfortunately,
i have no time, so am pleased that you see the importance of
getting this fixed. I will try to help out.
--David


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org