Ralf-
So digging into loadMapping question, when a Mapping object is created,
it creates a new DTDResolver and uses that unless the user calls
setEntityResolver to change it.
On my side note, I think I was having problems with the mapping DTD
because in the DTD itself, there is an example DOCTYPE line, which
doesn't match the one in DTDResolver. So when I put that in my file,
DTDResolver couldn't help, and Xerces went to URL specified (another
computer on our local network). When I set the DOCTYPE as DTDResolver
had it, DTDResolver did its job and the network wasn't needed.
So I think this solves the question of Castor's requirements, and what
remains is to examine what requirements user documents might have.
Thanks again,
Stephen
Stephen Bash wrote:
Ralf-
The DTDResolver edits sound promising. Where I really ran into the
problem was loadMapping, so I'll dig in there and see what resolver it
is using.
This may be a side issue, but looking online at the CVS, DTDResolver
still has a public ID of -//EXOLAB/Castor. For XMLBuddy in Eclipse to
recognize the mapping DTD, I had to change the public ID to
-//CODEHAUS/Castor, which would explain why even with the right version
of DTDResolver Xerces still tried to go out to the network. I was
always confused by this because the DTD still defines it as EXOLAB...
Any thoughts?
Now I guess I should think about how user's DTDs factor into the
equation. In my case, I want the DTDs/XSDs for editing while I'm
developing (yay for auto-complete), but I may run on a non-networked
computer at implementation time. So there probably will still be times
that non-Castor DTDs might be referenced and not be available... I'll
think about it more.
Thanks for your input.
Stephen
Ralf Joachim wrote:
Hi Stephen,
back in Decemeber Werner also worked on a solution at:
http://jira.codehaus.org/browse/CASTOR-1220
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.
Maybe we can configure to use DTDResolver or always use it which will
prevent us from configuring parser specific featurs.
What's your opinon on this idea?
Ralf
Stephen Bash schrieb:
Devs-
So back in December, Bryan Hansen complained on the user list about
Castor looking for DTDs on the network even though validation was turned
off (obviously a problem for non-networked computers). As was mentioned
back then, this is now default behavior in Xerces, and at the time, it
wasn't clear how to shut off this behavior.
Today after a little Googling I found there really is a Xerces feature
that will shut off this behavior:
http://apache.org/xml/features/nonvalidating/load-external-dtd
load-external-dtd defaults to true, and in order for Xerces not to fetch
external DTDs, it must be set to false. For reference, here's Xerces'
feature list (the above is the last feature listed in General Features):
http://xerces.apache.org/xerces-j/features.html
When I dug into Castor to find how to shut the feature off, I found a
couple solutions (in no particular order), and I'd like input as to
which is preferable:
1) Castor could set the feature to false by default. This would follow
the status quo that parsing features are only turned on. Then when a
user wanted Castor to fetch the DTD, they could put the above property
in org.exolab.castor.sax.features as normal. This might be problematic
when a parser other than Xerces is used.
2) To disable the feature (this follows hints from Keith), the user can
create their own instance of XMLReader, set the property to false, and
then unmarshal. Having tried this, I find it a little frustrating from
the user perspective (the user needs to know a lot about how Castor
deals with the parsing process).
3) A new property can be added that differentiates parser features to
turn on from parser features to turn off. This requires modifying
org.exolab.castor.util.Configuration (where property names are stored)
and LocalConfiguration (where the properties are actually used), but I
did this today and it seems to be an easy change. Then users just need
to add the load-external-dtd feature to the "off" feature list.
I'm not sure if a Jira issue was created or not. I'm willing to do that
(I think the testcase should be pretty easy), and if there is a
preferred resolution path, I can probably provide either the patch (for
options 1 or 3) or the code sample for users reference (option 2).
Thanks,
Stephen
-------------------------------------------------
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]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
