That's very interesting. It's a good day when you learn something. If I understand, I do not need to include a dtd; it is fetched from the log4j jar.
When and where does the the resolver get registered? This may very well be something I prevent from doing so. Setting a breakpoint will be nay impossible. But, I could - dare I say - try and place some System.out's. -S The traceback and specific version of log4j in use could be helpful. I doubt that it is actually Websphere "prepending" a path. It is most likely done by the XML parser. Relative URI's in an XML document are to be resolved relative to the document being parsed (unless there are xml:base attributes but lets ignore that). So somebody has to be in charge in resolving the URL and not just have it relative to the current working directory. log4j attempts to intercept the resolution of the dtd by registering o.a.log4j.xml.Log4jEntityResolver which attempts to substitute an copy of the log4j.dtd from the jar. Perhaps something is going wrong with that that we could fix. Any chance you could set a breakpoint in that could and see if it is reached and if it appears to be successful? That the parser gets it from the file system, suggests that the entity resolver was not called or failed. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
