Hi, Looks like everything has already been said. Still, there's a couple of small comments in-line.
Werner wg> -----Original Message----- wg> From: Stephen Bash [mailto:[EMAIL PROTECTED] wg> Sent: Friday, January 20, 2006 7:20 PM wg> To: [email protected] wg> Subject: Re: [castor-dev] Xerces Fetching DTDs wg> wg> Ralf- wg> wg> I think in the CVS version of the DTDResolver Werner has wg> hooks for both exolab and codehaus in the urls, I just wg> don't have that recent a version (need to upgrade, I know). +1. wg> As far as the public IDs, I myself am not real sure how wg> they work (especially in XML tools like XMLBuddy or wg> XMLSpy). Well, using e.g. XMLBuddy inside of Eclipse (or myEclipse at a client), these files then get marked as non-validatable as the public id points to "nowhere". With myEclipse, though, it's possible to specify a mapping from public id to a system id, allowing you to maintain a XML catalogue function (sort of). Wg> Once I put the public ID that DTDResolver had in wg> it into my mapping files, even the external XML tools were wg> happy with it, so I don't know if the public IDs need to be wg> changed or not (again, mostly because I don't know enough wg> about them). No, see above. All you need with most tools is a mapping as explained above. wg> I think the DTDResolver is (correctly) wg> working based on public ID right now rather than URL (since wg> my mapping docs point to a url on the local network and not wg> to the castor website). wg> wg> As I mentioned to Greg, documentation is probably the wg> biggest help here, though I still wonder if a "feature off" wg> capability in Castor would be helpful (unless this is the wg> only feature that defaults on). How about a HOW-TO document as a starting point .. ;-) ? wg> Thanks again for the discussion, and yes, a lower latency wg> form of communication might be helpful :) Well, you can always jump on IRC, can't you .. ? wg> Stephen wg> wg> wg> Ralf Joachim wrote: wg> > Stephen, wg> > wg> > Werner tried to change all DTD and XSD references in CVS wg> to point to wg> > codehaus even if he may have forgotten some as there are wg> quite a lot wg> > of them ;-) On the other side I'm sure that he did not change the wg> > public ID's as we both had not been aware of this requirement. I wg> > suggest to create a new issue in jira where we change the wg> public ID's wg> > and add anything that is required for the DTD's and XSD's wg> being loaded wg> > from jar/classpath. Having said that the intention of the wg> changes to wg> > DTDResolver was to load them as described above wg> independed of the url wg> > they refer to. Still we are not sure if we reached that target. wg> > wg> >>From your second mail it seams Werner managed to resolve wg> most of the wg> > original idea but not all. Still i think a new issue for wg> additional wg> > changes and documentation additions would be good. wg> > wg> > I'll try to manage that you can assign this issue to wg> yourself if you wg> > like to continue your work on it. If you like you may join: wg> > wg> > irc://irc.codehaus.org/castor wg> > wg> > sometime as this offers a shorter way for such wg> discussions. Werner and wg> > myself are quite frequently online. wg> > wg> > Regards wg> > Ralf wg> > wg> > wg> > wg> > Stephen Bash schrieb: wg> > wg> >>Ralf- wg> >> wg> >>The DTDResolver edits sound promising. Where I really wg> ran into the wg> >>problem was loadMapping, so I'll dig in there and see wg> what resolver it wg> >>is using. wg> >> wg> >>This may be a side issue, but looking online at the CVS, wg> DTDResolver wg> >>still has a public ID of -//EXOLAB/Castor. For XMLBuddy wg> in Eclipse to wg> >>recognize the mapping DTD, I had to change the public ID to wg> >>-//CODEHAUS/Castor, which would explain why even with the right wg> >>version of DTDResolver Xerces still tried to go out to wg> the network. I wg> >>was always confused by this because the DTD still defines wg> it as EXOLAB... wg> >>Any thoughts? wg> >> wg> >>Now I guess I should think about how user's DTDs factor into the wg> >>equation. In my case, I want the DTDs/XSDs for editing while I'm wg> >>developing (yay for auto-complete), but I may run on a wg> non-networked wg> >>computer at implementation time. So there probably will still be wg> >>times that non-Castor DTDs might be referenced and not be wg> available... wg> >>I'll think about it more. wg> >> wg> >>Thanks for your input. wg> >> wg> >>Stephen wg> >> wg> >> wg> >>Ralf Joachim wrote: wg> >> wg> >> wg> >>>Hi Stephen, wg> >>> wg> >>>back in Decemeber Werner also worked on a solution at: wg> >>> wg> >>>http://jira.codehaus.org/browse/CASTOR-1220 wg> >>> wg> >>>He changed DTDResolver to load DTD's and XSD's from wg> castor.jar but wg> >>>I'm not sure if the DTDResolver is used by default for loading wg> >>>mappings with XML and JDO. As far as I can remember the wg> DTDResolver wg> >>>is always used when loading jdo-conf.xml. wg> >>> wg> >>>Maybe we can configure to use DTDResolver or always use wg> it which will wg> >>>prevent us from configuring parser specific featurs. wg> >>> wg> >>>What's your opinon on this idea? wg> >>> wg> >>>Ralf wg> >>> wg> >>> wg> >>>Stephen Bash schrieb: wg> >>> wg> >>> wg> >>>>Devs- wg> >>>> wg> >>>>So back in December, Bryan Hansen complained on the wg> user list about wg> >>>>Castor looking for DTDs on the network even though wg> validation was wg> >>>>turned off (obviously a problem for non-networked wg> computers). As wg> >>>>was mentioned back then, this is now default behavior wg> in Xerces, and wg> >>>>at the time, it wasn't clear how to shut off this behavior. wg> >>>> wg> >>>>Today after a little Googling I found there really is a Xerces wg> >>>>feature that will shut off this behavior: wg> >>>> wg> >>>>http://apache.org/xml/features/nonvalidating/load-external-dtd wg> >>>> wg> >>>>load-external-dtd defaults to true, and in order for wg> Xerces not to wg> >>>>fetch external DTDs, it must be set to false. For wg> reference, here's Xerces' wg> >>>>feature list (the above is the last feature listed in wg> General Features): wg> >>>> wg> >>>>http://xerces.apache.org/xerces-j/features.html wg> >>>> wg> >>>>When I dug into Castor to find how to shut the feature wg> off, I found wg> >>>>a couple solutions (in no particular order), and I'd wg> like input as wg> >>>>to which is preferable: wg> >>>> wg> >>>>1) Castor could set the feature to false by default. wg> This would wg> >>>>follow the status quo that parsing features are only wg> turned on. wg> >>>>Then when a user wanted Castor to fetch the DTD, they wg> could put the wg> >>>>above property in org.exolab.castor.sax.features as wg> normal. This wg> >>>>might be problematic when a parser other than Xerces is used. wg> >>>> wg> >>>>2) To disable the feature (this follows hints from wg> Keith), the user wg> >>>>can create their own instance of XMLReader, set the property to wg> >>>>false, and then unmarshal. Having tried this, I find wg> it a little wg> >>>>frustrating from the user perspective (the user needs wg> to know a lot wg> >>>>about how Castor deals with the parsing process). wg> >>>> wg> >>>>3) A new property can be added that differentiates wg> parser features wg> >>>>to turn on from parser features to turn off. This requires wg> >>>>modifying org.exolab.castor.util.Configuration (where wg> property names wg> >>>>are stored) and LocalConfiguration (where the properties are wg> >>>>actually used), but I did this today and it seems to be an easy wg> >>>>change. Then users just need to add the wg> load-external-dtd feature to the "off" feature list. wg> >>>> wg> >>>>I'm not sure if a Jira issue was created or not. I'm wg> willing to do wg> >>>>that (I think the testcase should be pretty easy), and wg> if there is a wg> >>>>preferred resolution path, I can probably provide wg> either the patch wg> >>>>(for options 1 or 3) or the code sample for users wg> reference (option 2). wg> >>>> wg> >>>>Thanks, wg> >>>>Stephen wg> >>>> wg> >>>>------------------------------------------------- wg> >>>>If you wish to unsubscribe from this list, please send an empty wg> >>>>message to the following address: wg> >>>> wg> >>>>[EMAIL PROTECTED] wg> >>>>------------------------------------------------- wg> >>>> wg> >>> wg> >>> wg> >>------------------------------------------------- wg> >>If you wish to unsubscribe from this list, please send an empty wg> >>message to the following address: wg> >> wg> >>[EMAIL PROTECTED] wg> >>------------------------------------------------- wg> >> wg> > wg> > wg> wg> ------------------------------------------------- wg> If you wish to unsubscribe from this list, please send an wg> empty message to the following address: wg> wg> [EMAIL PROTECTED] wg> ------------------------------------------------- wg> wg> ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
