You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2005/04/12 16:03:55 UTC
Strange problem
Hi all,
I'm having an odd little problem here...
I have a webapp where I use Log4J underneath JCL. I use an XML config
file and Log4J is initialized in a ServletContextListener. The code in
the listener does some hackery on the XML... basically, I construct a real
path to my log files on the fly, update the XML and then configure logging
using the updated XML. Now, before anyone tells me how there are 10 other
and clearly better ways to do that (I have no doubt there are), the bottom
line is that this works and has worked for over a year. I've moved it
between Tomcat (on both Windows and Linux) and Websphere (and earlier
version) with no issue.
The problem now though is that I'm deploying it on a newer Websphere
(5.1.1) on Windows... what's happening is that the log files are created
and are locked (i.e., I can't delete them), and they are where they are
supposed to be (a logs directory under my webapp), so everything SEEMS to
be starting up fine and as expected. However, no messages are making it
to the log files. They are showing up in Websphere's stdout and stderr
logs instead. So, I'm not sure this is a Log4J problem or strictly a
Websphere issue, but I'm hoping someone has seem a similar issue and can
shed some light on it.
I'm not seeing any messages indicating problems anywhere, for all intents
and purposes it appears like it should be working just fine.
Note that this very same code runs perfectly as you see it below (I did
remove spaces and comments to shorten the post though) under Tomcat, so it
truly is something Websphere-related, but whether I can configure Log4J in
some different way or not to overcome it is what I don't know.
Here's my config file:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<param name="Threshold" value="DEBUG"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %l %x- %m\n" />
</layout>
</appender>
<appender name="TOAINFOFILE" class="org.apache.log4j.FileAppender">
<param name="Threshold" value="DEBUG"/>
<param name="File" value="c:\\tomcat\\webapps\\toa\\logs\\toaInfo.log"/>
<param name="Append" value="false"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %l %x- %m\n" />
</layout>
</appender>
<appender name="TOAERRORFILE" class="org.apache.log4j.FileAppender">
<param name="Threshold" value="ERROR"/>
<param name="File" value="c:\\tomcat\\webapps\\toa\\logs\\toaError.log"/>
<param name="Append" value="false"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %l %x- %m\n" />
</layout>
</appender>
<appender name="TOAAGINGFILE" class="org.apache.log4j.FileAppender">
<param name="Threshold" value="DEBUG"/>
<param name="File" value="c:\\tomcat\\webapps\\toa\\logs\\toaAging.log"/>
<param name="Append" value="false"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %l %x- %m\n" />
</layout>
</appender>
<category name="com.company" additivity="true">
<appender-ref ref="CONSOLE" />
<appender-ref ref="TOAINFOFILE" />
<appender-ref ref="TOAERRORFILE" />
</category>
<category name="com.company.toa.daemonthreads.AgingProcessDaemonThread"
additivity="true">
<appender-ref ref="TOAAGINGFILE" />
</category>
</log4j:configuration>
And here's my ContextListener:
import java.io.BufferedReader;
import java.io.ByteArrayInputStream;
import java.io.File;
import java.io.FileReader;
import java.io.InputStream;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.log4j.LogManager;
import org.apache.log4j.xml.DOMConfigurator;
public class TOAServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
System.out.println(this.getClass().getName() +
" - Initializing Logging...");
try {
ServletContext sc = sce.getServletContext();
String lConfigFile = sc.getRealPath("/WEB-INF/loggingConfig.xml");
lPath += File.separator;
lPath = TOAHelpers.strReplace(lPath, "\\", "\\\\");
FileReader fr = new FileReader(lConfigFile);
BufferedReader br = new BufferedReader(fr);
StringBuffer sbXML = new StringBuffer();
String line = "";
while ((line = br.readLine()) != null) { sbXML.append(line); }
br.close();
String xml = sbXML.toString();
xml = TOAHelpers.strReplace(xml,
"<param name=\"File\" value=\"", "<param name=\"File\"
value=\"" +
lPath);
InputStream isXML = new ByteArrayInputStream(xml.getBytes());
new DOMConfigurator().doConfigure(isXML,
LogManager.getLoggerRepository());
Log log = LogFactory.getLog(getClass());
log.info("Log4J initialized");
} catch (Exception e) {
System.err.println("Exception in TOAServletContextListener(): " + e);
}
}
public void contextDestroyed(ServletContextEvent sce) { }
}
Thanks in advance!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:25 PM 4/12/2005, Frank W. Zammetti wrote:
>I didn't update all copies... I didn't realize I had to as I thought the
>version local to the webapp would be all that matters (is this by any
>chance the much-discussed autodiscovery/classloader issue rearing its ugly
>head??)
If I am not mistaken, by default Websphere uses the parent-first class
loader delegation model which goes to explain the behavior you are observing.
>I also did not update commons-logging-api.jar as I don't have that
>installed with my app, only commons-logging.jar is present.
Although not generally truem, in this particular case, parent-first
delegation implies that the copy of JCL in your web-app will be ignored.
>I'll go hunt down all copies now and update them, see what happens...
>
>--
>Frank W. Zammetti
>Founder and Chief Software Architect
>Omnytex Technologies
>http://www.omnytex.com
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I didn't update all copies... I didn't realize I had to as I thought the
version local to the webapp would be all that matters (is this by any
chance the much-discussed autodiscovery/classloader issue rearing its ugly
head??)
I also did not update commons-logging-api.jar as I don't have that
installed with my app, only commons-logging.jar is present.
I'll go hunt down all copies now and update them, see what happens...
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Tue, April 12, 2005 1:59 pm, Ceki Gülcü said:
> Frnak,
>
> Did you make sure to upgrade *all* copies of commons-logging.jar to 1.0.4?
> I believe Websphere has its own copy of JCL. Did you make sure also to
> upgrade commons-logging-api.jar?
>
> At 07:49 PM 4/12/2005, Frank W. Zammetti wrote:
>>Further info...
>>
>>I updated JCL to 1.0.4 and removed the
>>org.apache.commons.logging.LogFactory file... logging broke again. I put
>>the file back, restarted the app, and logging was once again working.
>>
>>Log4J version is 1.2.8 incidentally, so I was almost up to date with that
>>as well (have NOT updated to 1.2.9).
>>
>>Any ideas? I have no problem believing I don't have the right answer at
>>this point, but it does certainly appear to be fixing the problem
>> somehow.
>> Thanks!
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by Ceki Gülcü <ce...@qos.ch>.
Frnak,
Did you make sure to upgrade *all* copies of commons-logging.jar to 1.0.4?
I believe Websphere has its own copy of JCL. Did you make sure also to
upgrade commons-logging-api.jar?
At 07:49 PM 4/12/2005, Frank W. Zammetti wrote:
>Further info...
>
>I updated JCL to 1.0.4 and removed the
>org.apache.commons.logging.LogFactory file... logging broke again. I put
>the file back, restarted the app, and logging was once again working.
>
>Log4J version is 1.2.8 incidentally, so I was almost up to date with that
>as well (have NOT updated to 1.2.9).
>
>Any ideas? I have no problem believing I don't have the right answer at
>this point, but it does certainly appear to be fixing the problem somehow.
> Thanks!
>
>--
>Frank W. Zammetti
>Founder and Chief Software Architect
>Omnytex Technologies
>http://www.omnytex.com
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Further info...
I updated JCL to 1.0.4 and removed the
org.apache.commons.logging.LogFactory file... logging broke again. I put
the file back, restarted the app, and logging was once again working.
Log4J version is 1.2.8 incidentally, so I was almost up to date with that
as well (have NOT updated to 1.2.9).
Any ideas? I have no problem believing I don't have the right answer at
this point, but it does certainly appear to be fixing the problem somehow.
Thanks!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Tue, April 12, 2005 1:28 pm, Frank W. Zammetti said:
> Hi Ceki,
>
> I am using an older version, but not *that* old... 1.0.3
>
> Would you expect that upgrading from 1.0.3 to 1.0.4 (the latest production
> release I can see) and also removing the
> org.apache.commons.logging.LogFactory file would result in my logging
> still working as it does now with that file?
>
> I'm certainly willing to give it a try if you are telling that is the the
> correct answer (you would know better than me certainly!) :)
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Tue, April 12, 2005 1:20 pm, Ceki Gülcü said:
>>
>> Frank,
>>
>> What you suggest sounds quite wrong to me. In particular,
>> org.apache.commons.logging.impl.Log4jFactory is deprecated [1] and
>> should
>> not be used. The fact that setting org.apache.commons.logging.LogFactory
>> gives positive results indicates that you may be using an old version of
>> JCL as James suspected you were.
>>
>> [1]
>> http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/Log4jFactory.html
>>
>> At 06:07 PM 4/12/2005, Frank W. Zammetti wrote:
>>>Thanks James, that did put me on the right track... just for the sake of
>>>having an answer in the archives, what solved the problem for me is
>>> adding
>>>the following file...
>>>
>>>org.apache.commons.logging.LogFactory
>>>
>>>...(yes, that is the full filename!), with the contents...
>>>
>>>org.apache.commons.logging.impl.Log4jFactory
>>>
>>>... stored under META-INF/services in the root of the webapp (so that it
>>>is part of the WAR within the EAR).
>>>
>>> >From what I gather, Websphere wants to take over logging with its
>>>proprietary logging subsystem, and this basically tells it "No, no, bad
>>>app server! Use what *I* say to use!"
>>>
>>>So, while not strictly a Log4J issue, I can see this coming up again for
>>>others, so hope it helps someone down the road!
>>>
>>>--
>>>Frank W. Zammetti
>>>Founder and Chief Software Architect
>>>Omnytex Technologies
>>>http://www.omnytex.com
>>
>> --
>> Ceki Gülcü
>>
>> The complete log4j manual: http://www.qos.ch/log4j/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Hi Ceki,
I am using an older version, but not *that* old... 1.0.3
Would you expect that upgrading from 1.0.3 to 1.0.4 (the latest production
release I can see) and also removing the
org.apache.commons.logging.LogFactory file would result in my logging
still working as it does now with that file?
I'm certainly willing to give it a try if you are telling that is the the
correct answer (you would know better than me certainly!) :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Tue, April 12, 2005 1:20 pm, Ceki Gülcü said:
>
> Frank,
>
> What you suggest sounds quite wrong to me. In particular,
> org.apache.commons.logging.impl.Log4jFactory is deprecated [1] and should
> not be used. The fact that setting org.apache.commons.logging.LogFactory
> gives positive results indicates that you may be using an old version of
> JCL as James suspected you were.
>
> [1]
> http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/Log4jFactory.html
>
> At 06:07 PM 4/12/2005, Frank W. Zammetti wrote:
>>Thanks James, that did put me on the right track... just for the sake of
>>having an answer in the archives, what solved the problem for me is
>> adding
>>the following file...
>>
>>org.apache.commons.logging.LogFactory
>>
>>...(yes, that is the full filename!), with the contents...
>>
>>org.apache.commons.logging.impl.Log4jFactory
>>
>>... stored under META-INF/services in the root of the webapp (so that it
>>is part of the WAR within the EAR).
>>
>> >From what I gather, Websphere wants to take over logging with its
>>proprietary logging subsystem, and this basically tells it "No, no, bad
>>app server! Use what *I* say to use!"
>>
>>So, while not strictly a Log4J issue, I can see this coming up again for
>>others, so hope it helps someone down the road!
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by Ceki Gülcü <ce...@qos.ch>.
Frank,
What you suggest sounds quite wrong to me. In particular,
org.apache.commons.logging.impl.Log4jFactory is deprecated [1] and should
not be used. The fact that setting org.apache.commons.logging.LogFactory
gives positive results indicates that you may be using an old version of
JCL as James suspected you were.
[1]
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/Log4jFactory.html
At 06:07 PM 4/12/2005, Frank W. Zammetti wrote:
>Thanks James, that did put me on the right track... just for the sake of
>having an answer in the archives, what solved the problem for me is adding
>the following file...
>
>org.apache.commons.logging.LogFactory
>
>...(yes, that is the full filename!), with the contents...
>
>org.apache.commons.logging.impl.Log4jFactory
>
>... stored under META-INF/services in the root of the webapp (so that it
>is part of the WAR within the EAR).
>
> >From what I gather, Websphere wants to take over logging with its
>proprietary logging subsystem, and this basically tells it "No, no, bad
>app server! Use what *I* say to use!"
>
>So, while not strictly a Log4J issue, I can see this coming up again for
>others, so hope it helps someone down the road!
>
>--
>Frank W. Zammetti
>Founder and Chief Software Architect
>Omnytex Technologies
>http://www.omnytex.com
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Thanks James, that did put me on the right track... just for the sake of
having an answer in the archives, what solved the problem for me is adding
the following file...
org.apache.commons.logging.LogFactory
...(yes, that is the full filename!), with the contents...
org.apache.commons.logging.impl.Log4jFactory
... stored under META-INF/services in the root of the webapp (so that it
is part of the WAR within the EAR).
>From what I gather, Websphere wants to take over logging with its
proprietary logging subsystem, and this basically tells it "No, no, bad
app server! Use what *I* say to use!"
So, while not strictly a Log4J issue, I can see this coming up again for
others, so hope it helps someone down the road!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Tue, April 12, 2005 10:34 am, James Stauffer said:
> That sounds similar to a problem that I had recently. Search the
> archives for messages with a subject of "JCL+Tomcat+Log4j related
> problems". Basically I was having problems because my JCL jars were
> too old.
>
> On Apr 12, 2005 9:03 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> Hi all,
>>
>> I'm having an odd little problem here...
>>
>> I have a webapp where I use Log4J underneath JCL. I use an XML config
>> file and Log4J is initialized in a ServletContextListener. The code in
>> the listener does some hackery on the XML... basically, I construct a
>> real
>> path to my log files on the fly, update the XML and then configure
>> logging
>> using the updated XML. Now, before anyone tells me how there are 10
>> other
>> and clearly better ways to do that (I have no doubt there are), the
>> bottom
>> line is that this works and has worked for over a year. I've moved it
>> between Tomcat (on both Windows and Linux) and Websphere (and earlier
>> version) with no issue.
>>
>> The problem now though is that I'm deploying it on a newer Websphere
>> (5.1.1) on Windows... what's happening is that the log files are created
>> and are locked (i.e., I can't delete them), and they are where they are
>> supposed to be (a logs directory under my webapp), so everything SEEMS
>> to
>> be starting up fine and as expected. However, no messages are making it
>> to the log files. They are showing up in Websphere's stdout and stderr
>> logs instead. So, I'm not sure this is a Log4J problem or strictly a
>> Websphere issue, but I'm hoping someone has seem a similar issue and can
>> shed some light on it.
>
> --
> James Stauffer
> Are you good? Take the test at http://www.livingwaters.com/good/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Strange problem
Posted by James Stauffer <st...@gmail.com>.
That sounds similar to a problem that I had recently. Search the
archives for messages with a subject of "JCL+Tomcat+Log4j related
problems". Basically I was having problems because my JCL jars were
too old.
On Apr 12, 2005 9:03 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Hi all,
>
> I'm having an odd little problem here...
>
> I have a webapp where I use Log4J underneath JCL. I use an XML config
> file and Log4J is initialized in a ServletContextListener. The code in
> the listener does some hackery on the XML... basically, I construct a real
> path to my log files on the fly, update the XML and then configure logging
> using the updated XML. Now, before anyone tells me how there are 10 other
> and clearly better ways to do that (I have no doubt there are), the bottom
> line is that this works and has worked for over a year. I've moved it
> between Tomcat (on both Windows and Linux) and Websphere (and earlier
> version) with no issue.
>
> The problem now though is that I'm deploying it on a newer Websphere
> (5.1.1) on Windows... what's happening is that the log files are created
> and are locked (i.e., I can't delete them), and they are where they are
> supposed to be (a logs directory under my webapp), so everything SEEMS to
> be starting up fine and as expected. However, no messages are making it
> to the log files. They are showing up in Websphere's stdout and stderr
> logs instead. So, I'm not sure this is a Log4J problem or strictly a
> Websphere issue, but I'm hoping someone has seem a similar issue and can
> shed some light on it.
--
James Stauffer
Are you good? Take the test at http://www.livingwaters.com/good/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org