Greg-
The more I think about the problem, the more I agree with you. I think
a lot of my troubles came from not understanding the EntityResolver
interface and it's behavior.
Perhaps the correct solution is to include a EntiryResolver/DTDResolver
"tutorial" (for lack of a better word) in the new XML HOW-TO to raise
user awareness as to the right way to handle these external references.
Thanks,
Stephen
Gregory Block wrote:
On 20 Jan 2006, at 16:27, Ralf Joachim wrote:
He changed DTDResolver to load DTD's and XSD's from castor.jar but I'm
not sure if the DTDResolver is used by default for loading mappings with
XML and JDO. As far as I can remember the DTDResolver is always used
when loading jdo-conf.xml.
EntityResolver is a safer bet for the insertion - and provides a place
to handle user-specific entity resolvers if you build an 'internal'
resolver that chains by calling the parent set by the user.
This is what we do here - we insert a series off resolvers that
handle... let's see... First it attempts to get a cached version from
our caching HTTP client, built with memcached and HTTPClient; then it
attempts source-specific resolvers (for example, content which comes
out of the Slide DAV API from our DAV servers will attempt to resolve
to other DAV files in that path), then it attempts a few others.
The benefit of doing this is that the parser is able to resolve
entities from these documents - not loading those entities means they
can't be resolved by the underlying parser, which can be a problem.
My recommendation is that Castor should always, on all requests to
parse, ensure that it includes an EntityResolver; that entity resolver
should catch requests for 'internal' entities such as the DTDs, and
pass all other requests to the entity resolver provided by clients.
Alternately, people are free to roll their own. Actual parsing can be
done without this mess just by getting the handler directly from castor
instead of letting it do the heavy lifting, and it's not much code.
What this *can't* be done with is the one thing you'd want to: you
can't take control over the parsing of mapping files; that means that
mapping files don't run with the entity resolver, and those requests
will be forced through.
All you need is EntityResolver API. It'll catch the DTD requests as
well as anything else.
-------------------------------------------------
If you wish to unsubscribe from this list, please send an empty message
to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
