10 89 2007-09-07T11:24:12-04:00 $Date$ NormanWalsh 2007Norman Walsh Take advantage of the catalog resolver built into GlassFish to treat your neighbors more gently and maybe improve performance. By its very nature, the web encourages dereference of URIs. This is a good thing, it's how we surf the web in our browser of choice and it's how web applications take advantage of distributed resources. The more popular a resource is, the more likely it is to get dereferenced. This too, is usually a good thing. Lots of folks keep track of the number of “hits” they get (for weblog postings, press releases, product downloads, etc.). More is better. But it is possible to get too much of a good thing, especially where web applications are concerned. A popular web application can hit a resource thousands of times an hour (maybe more), faster than even the most caffeine-fueled web surfer. The W3C, for example, gets an astonishing number of hits for DTDs (especially the HTML and XHTML DTDs), schemas, and namespace documents. So many, in fact, that sometimes it looks like a denial-of-service attack. And sometimes that'll get you locked out completely for several days. Addressing the problem of scalable access to web resources is not a simple one. There are a number of ways it can be approached at a number of different levels in the web architecture stack. The W3C Technical Architecture Group has agreed to investigate the issue. In the meantime, if you're writing GlassFish servlets or other applications that are performing XML processing, you can take advantage of the XML CatalogXML Catalogs OASIS Standard V1.1, 7 October 2005 resolver built into GlassFish to directly reduce the burden your applications are creating. (Never heard of a XML Catalogs? I wrote some background information a while back.) The secret is to make local copies of static resources and then tell the catalog resolver to use them instead. I'm going to use the XHTML DTD for my example, but it applies to any web resource that your application might be accessing. The first step is to make local copies of the representations you need and then create an XML Catalog for them. In this case, I grabbed the xhtml1-transitional.dtd file and the entities it relies on and built this catalog: ]]> The next step relies on the fact that GlassFish ships with the entity resolver that was developed as part of the Apache XML Commons project. All you have to do is make sure that it's used as the entity resolver or URI resolver by your application. In the interest of choosing a simple, common example, let's look at how we can use this resolver if we're parsing a document with SAX. First, make sure that you're importing the resolver: import com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver; I know this ships with GlassFish, but if you're uncomfortable with the slightly dubious practice of relying on “private” classes, you can install the standard distribution yourself. (And if you're using NetBeans, you can skip right over the import step, NetBeans will suggest the import for you when you need it and stick it in the right place.) Next, make yourself a catalog resolver: CatalogResolver resolver = new CatalogResolver(); And finally, make sure it gets used. I setup my own SAX handler and used it in there: private class MyHandler extends DefaultHandler { public InputSource resolveEntity(String publicId, String systemId) throws IOException, SAXException { return resolver.resolveEntity(publicId, systemId); } } The complete class file is available if you want to see all the code. I hacked the “hello2” example from Chapter 2 of The Java EE 5 Tutorial. It treats the “name” you give it as a URI and attempts to parse it. In the GlassFish context, there's one more step. You have to configure the server so that it sets the xml.catalog.files system property to point to your catalog. (There are other ways of getting to the right catalog, but this is the simplest.) I added the system property to the domain configuration file: ]]> Of course, /tmp/ is a silly place to put the file, but it was enough for this demonstration. Not only do you get the benefit of being a better net citizen by using a resolver to reduce your burden on your net neighbors, but you may see a performance improvement as well. No matter how good your server bandwidth is, it's still slower to hit the net than your local file system. Next time, we'll look at using some slightly more bleeding edge code to avoid the task of constructing the catalog by hand.