Ralf-
I think in the CVS version of the DTDResolver Werner has hooks for both
exolab and codehaus in the urls, I just don't have that recent a version
(need to upgrade, I know).
As far as the public IDs, I myself am not real sure how they work
(especially in XML tools like XMLBuddy or XMLSpy). Once I put the
public ID that DTDResolver had in it into my mapping files, even the
external XML tools were happy with it, so I don't know if the public IDs
need to be changed or not (again, mostly because I don't know enough
about them). I think the DTDResolver is (correctly) working based on
public ID right now rather than URL (since my mapping docs point to a
url on the local network and not to the castor website).
As I mentioned to Greg, documentation is probably the biggest help here,
though I still wonder if a "feature off" capability in Castor would be
helpful (unless this is the only feature that defaults on).
Thanks again for the discussion, and yes, a lower latency form of
communication might be helpful :)
Stephen
Ralf Joachim wrote:
Stephen,
Werner tried to change all DTD and XSD references in CVS to point to
codehaus even if he may have forgotten some as there are quite a lot of
them ;-) On the other side I'm sure that he did not change the public
ID's as we both had not been aware of this requirement. I suggest to
create a new issue in jira where we change the public ID's and add
anything that is required for the DTD's and XSD's being loaded from
jar/classpath. Having said that the intention of the changes to
DTDResolver was to load them as described above independed of the url
they refer to. Still we are not sure if we reached that target.
From your second mail it seams Werner managed to resolve most of the
original idea but not all. Still i think a new issue for additional
changes and documentation additions would be good.
I'll try to manage that you can assign this issue to yourself if you
like to continue your work on it. If you like you may join:
irc://irc.codehaus.org/castor
sometime as this offers a shorter way for such discussions. Werner and
myself are quite frequently online.
Regards
Ralf
Stephen Bash schrieb:
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]
-------------------------------------------------
