Failover of Deployment Descriptor s

[Kiran Kumar]

Hello Experts,

We all know that web.xml and application.xml have

  <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
  

and

 <!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
   

.. respectively.

They reference the DTDs on java.sun.com. So, my application depends on the DTD's on an external site. How do I maintain fail over as I don't want my applications to fail incase the DTDs are temporarily down at java.sun.com.

I know that I can have the DTDs copied and put as inline DTDs in my deployment descriptors, but I was thinking about hosting these DTDs on my company's servers and making my deployment descriptors point to them. But, my deployment fails for some reason. Is there more configuration to do in this regard?

In my investigation I read about Catalog files etc. Is that the way to go? If yes, how is it done?

Any pointers appreciated!
Thanks in advance,
Kiran

[Reid M. Pinchback]

You'll probably find that your appserver already has an internal catalog providing these DTDs to itself. If a particular DTD isn't there by default, I believe some appservers (WebLogic) allow you to configure the catalog. If neither is true and you are really worried about it, try changing the system id to a local directory and cache your own copies of those DTDs.
[ February 15, 2006: Message edited by: Reid M. Pinchback ]

[Kiran Kumar]

Reid,

Thanks for the reply.

Unfortunately, my app server doesn't provide me any documentation if it provides a provision of configuring catalog files. I use SAP Web AS 6.40, incase something strikes for someone reading this article. I guess having DTDs in the war/ear is the way to go. In that case, how does my <!DOCTYPE looks like?

I tried

code:
--------------------------------------------------------------------------------

<!DOCTYPE application SYSTEM "application_1_3.dtd">
and
<!DOCTYPE application SYSTEM "file://application_1_3.dtd">


--------------------------------------------------------------------------------



and putting application_1_3.dtd in my META-INF directory. But it fails.


Thanks,
Kiran

[Reid M. Pinchback]

Right idea, wrong place. For the particular DTDs you are concerned about it isn't your application code that needs to find the files, it is your appserver's code that needs to find them. That means the classpath specific to your app isn't relevant. You either need to specify an *absolute* path on your filesystem (in the case of your second example), or figure out how to add something to a location your appserver will recognize as being on its own classpath (in the case of your first example). It has been awhile since I mucked with SAP, don't recall the specifics, but in most web or J2EE servers there is a directory that you can add jars to and they'll end up on the server classpath. You could jar up these DTDs (not in META-INF, just at top-level of the jar), and drop that jar in with the other appserver libs.

[Kiran Kumar]

Reid,

I know what you are talking about and unfortunately SAP's server is very highly coupled with its IDE and allows only rigid procedures to be followed without much flexibility. For now, I am planning to have the DTDs as internal to my DDs though it's a nasty solution.

Thanks,
Kiran

[Reid M. Pinchback]

I can see why it sounds like you are constrained, but unfortunately that isn't going to make the technology behave differently if SAP uses a parser that works anything like Xerces or Crimson. The question comes down to knowing what the search space is going to be, i.e. if your app resources are or aren't included in resolving a relative path for a DTD. You very likely have to do something that impacts the appserver itself, which means something that happens before your app is even deployed. You can try dropping these DTD files into a root package (e.g. in a jar in your ear) and keep your fingers crossed, but I wouldn't be surprised if that doesn't work. It should only work if the appserver is using the ear's own classloader to find relative-pathed DTD files used to validate the structure of its own deployment descriptor. Not impossible, but not what I'd expect the appserver to do. If nothing else, try experimenting with dropping files somewhere in the jdk/jre used by the appserver, like the endorsed directory.

If there is a *business* reason why you have to find a solution specific to bundling the files into a war or ear, then unfortunately you may be well and truly hosed *unless* you are willing to deploy a second trivial webapp to serve copies of those DTD files. You could change that system id to refer to a site of your own instead of Suns. A goofy way to do it, and will only work if you can control the deployment order in SAP, but the only other option I know of.

And no matter how integrated the browser is, I don't see why you are blocked from specifying an absolute file location for the server to find the DTD files. That is like saying the browser constrains the JDK running the appserver. It should be no different from you doing something like specifying an absolute file location for storing Log4J output.
[ February 16, 2006: Message edited by: Reid M. Pinchback ]