Log4j config file on Websphere

[Steve Pruitt <SP...@exstream.com>]

All, 

This is not a log4j problem per se, but maybe someone has a going
Websphere deployment.

Has anyone successfully deployed Log4j on Websphere?  I cannot find the
right solution for the DOCTYPE SYSTEM path. The problem is getting
Websphere to stop prepending a path to the setting. The dtd is located
in the same folder as the xml file that references it. WEB-INF being
that folder.

As an example, the following

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

produces

java.io.FileNotFoundException: C:\Program
Files\WebSphere\AppServer\log4j.dtd (The system cannot find the file
specified)


Thanks,

SP


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

Re: Log4j config file on Websphere

[Curt Arnold <ca...@apache.org>]

On Jul 29, 2005, at 10:32 AM, Steve Pruitt wrote:

> All,
>
> This is not a log4j problem per se, but maybe someone has a going
> Websphere deployment.
>
> Has anyone successfully deployed Log4j on Websphere?  I cannot find  
> the
> right solution for the DOCTYPE SYSTEM path. The problem is getting
> Websphere to stop prepending a path to the setting. The dtd is located
> in the same folder as the xml file that references it. WEB-INF being
> that folder.
>
> As an example, the following
>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
>
> produces
>
> java.io.FileNotFoundException: C:\Program
> Files\WebSphere\AppServer\log4j.dtd (The system cannot find the file
> specified)


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: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org