struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Should dtd's be kept locally and referenced locally or just take from the web?
Date Thu, 10 Jul 2003 07:55:39 GMT


On Thu, 10 Jul 2003, Tin Pham wrote:

> Date: Thu, 10 Jul 2003 02:59:35 -0400
> From: Tin Pham <ttpham3@learn.senecac.on.ca>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message