Hi David,
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.
>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:
/**
* JUnit test case:
* Ask for an entity using a systemId, expressed as a URN
*
* @exception Exception Description of Exception
* @since
*/
public void testResolveURNSystemIdentity() throws Exception {
assertNotNull("ResolverImpl is null", resolverImpl);
String public_id;
String system_id;
InputSource is;
public_id = null;
system_id = "urn:x-pigbite:person";
is = resolverImpl.resolveEntity(public_id, system_id);
assertNotNull("InputSource is null for " +
"'" + public_id + "'" + ", " +
"'" + system_id + "'", is);
// close the entity stream, otherwise removing it will fail
// (note that normally the parser would handle this)
java.io.Reader entity_r = is.getCharacterStream();
if (entity_r != null) {
entity_r.close();
}
java.io.InputStream entity_is = is.getByteStream();
if (entity_is != null) {
entity_is.close();
}
is = null;
}
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.
I have not noticed any problems running build docs but you have made me
curious as to if there are any issues there! Do you have anything in mind
that might be wrong? If I remember correctly, docs is the only bit where
validation is forced...
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 ;-).
Regards
Jeremy
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
