On Thu, 10 Jul 2003, Tin Pham wrote:
> Date: Thu, 10 Jul 2003 02:59:35 -0400 > From: Tin Pham <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Should dtd's be kept locally and referenced locally or just take > from the web? > > Hi, > > Does anybody have any opinions on whether my dtd's should be downloaded and > referenced locally or put on the web? > > What happens if you go into production and the online reference is down? > > The app server type I am using is WebSphere. > If you've got anything like my typical use case, you'll consider a third path ... which happens to be the one that Struts and Tomcat both use. At home, I've got DSL with the typical "always on" network connection. The download speed is fast enough that I wouldn't notice the download time -- it's sufficientily fast that having to access the DTD remotely is effectively transparent, so I wouldn't normally notice it. Now, I get ready to present a session at some conference, including the execution of a demo application. On the airplane flying to the conference, I do "one last check" to make sure that everything is working correctly -- but, of course, I'm not connected to the Internet, so every attempt to execute my application fails because the DTD cannot be downloaded ... panic!!! Fortunately, most conferences nowdays provide live Internet connections for the presenter, so at least my demo app will still work for the live session ... that is, assuming that the network is actually working during the time I'm actually presenting my session. I don't know about you, but I believe in the a variation of Murphy's Law called the "critical need detector" -- at exactly the moment you need it most, something is going to go wrong. All of the above is a (hopefully enjoyable) background to a suggestion of how you can use a network-based system identifier (the third string in a DOCTYPE declaration) even in a computer disconnected from the network -- if you are using a JAXP-based parser to parse your XMl documents, you can replace the EntityResolver that actually goes and reads the DTD with one that references a local copy instead. Since you can match the public identifier (the second string) to a local copy of the DTD, your app will run fine disconnected from the Internet (or even your local company intranet). If you'd like to see a real-life example of this technique (which is directly applicable to anyone who uses commons-digester to parse your XML documents), check out the use of the Digester.register() method in the initConfigDigester() method of the org.apache.struts.action.ActionServlet class -- what happens is that Struts registers a reference to it's local copy of the DTD based on matching the public identifier in the DOCTYPE of the document you are parsing. Tomcat plays the same sort of game when parsing web.xml files -- check out the logic in the org.apache.catalina.startup.ContextConfig class. Tomcat is constrained by the requirement that it needs to accept *any* web.xml file that includes the DOCTYPE declaration mandated by the servlet specification, so it basically has to work on a disconnected computer. This technique lets you establish persistent system identifiers that happen to work when connected to your corporate intranet, but do not suddenly fail when you have the chance to show off your cool application at something like JavaOne :-). > Thanks. > Craig McClanahanan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
