posted 19 years ago
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 ]
Reid - SCJP2 (April 2002)