Problem with Junit swing TestRunner and log4j 1.2.7

[Gary Clayburg]

I'm running into a problem with log4j configuration when running junit 
tests from the junit.swingui.TestRunner class.
Here is the error message I get to the console:

log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not 
assignable to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [junit.runner.TestCaseClassLoader@a9255c] whereas object of 
type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by 
[sun.misc.Launcher$AppClassLoader@12f6684].
log4j:ERROR Could not instantiate appender named "A1".
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not 
assignable to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [junit.runner.TestCaseClassLoader@a9255c] whereas object of 
type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by 
[sun.misc.Launcher$AppClassLoader@12f6684].
log4j:ERROR Could not instantiate appender named "A1".
log4j:WARN No appenders could be found for logger (TestOmaha).
log4j:WARN Please initialize the log4j system properly.

These errors go away completely  if I specify -Dlog4j.ignoreTCL on the 
command line like this:

java -Dlog4j.ignoreTCL junit.swingui.TestRunner

This, of course, causes log4j to use Class.forName() to load 
org.apache.log4j.ConsoleAppender.

The junit swing test runner has a default option to reload classes 
everytime you click the "run" button.  This is a good thing so you can 
avoid restarting the gui.  The problem with log4j though, is that this 
is causing log4j to load the classes "org.apache.log4j.Appender" and 
"org.apache.log4j.ConsoleAppender" with different classloaders as seen 
in the error message.  The Appender class seems to be loaded as a 
regular java class (probably via new), but the ConsoleAppender is being 
loaded by this special Thread Context Classloader.  This Appender class 
is being loaded via this special junit class loader, 
"junit.runner.TestCaseClassLoader@a9255c".  ConsoleAppender needs to be 
loaded by either the same classloader used to load the Appender class or 
a child of that classloader.  It appears that log4j is using attempting 
to use a  parent of the classloader used to load Appender here.

What is the motivation is for using this Thread Context Classloader by 
default anyway?  

I haven't worked much with this Thread Context Classloader much, but 
accourding to the docs, getContextClassLoader() will return the the 
ClassLoader context of the parent Thread if setContextClassLoader() is 
not used.  In fact, you can see this behavior by clicking the "run" 
button with the junit swing TestRunner.  The Appender class is always 
loaded from a NEW classloader, but the ConsoleAppender class is always 
attempted to be loaded by the SAME classloader each time - i.e. the 
ConsoleAppender is being loaded by this one Thread Context Classloader 
that knows nothing about new classloaders being created by junit.

Does this make sense to anyone?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Problem with Junit swing TestRunner and log4j 1.2.7

[Ceki Gülcü]

At 05:23 10.01.2003 -0700, you wrote:

I'm running into a problem with log4j configuration when running junit 
tests from the junit.swingui.TestRunner class.
Here is the error message I get to the console:

log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable 
to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [junit.runner.TestCaseClassLoader@a9255c] whereas object of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by 
[sun.misc.Launcher$AppClassLoader@12f6684].
log4j:ERROR Could not instantiate appender named "A1".
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable 
to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [junit.runner.TestCaseClassLoader@a9255c] whereas object of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by 
[sun.misc.Launcher$AppClassLoader@12f6684].
log4j:ERROR Could not instantiate appender named "A1".
log4j:WARN No appenders could be found for logger (TestOmaha).
log4j:WARN Please initialize the log4j system properly.

These errors go away completely  if I specify -Dlog4j.ignoreTCL on the 
command line like this:

java -Dlog4j.ignoreTCL junit.swingui.TestRunner

This, of course, causes log4j to use Class.forName() to load 
org.apache.log4j.ConsoleAppender.

The junit swing test runner has a default option to reload classes 
everytime you click the "run" button.  This is a good thing so you can 
avoid restarting the gui.  The problem with log4j though, is that this is 
causing log4j to load the classes "org.apache.log4j.Appender" and 
"org.apache.log4j.ConsoleAppender" with different classloaders as seen in 
the error message.  The Appender class seems to be loaded as a regular 
java class (probably via new), but the ConsoleAppender is being loaded by 
this special Thread Context Classloader.  This Appender class is being 
loaded via this special junit class loader, 
"junit.runner.TestCaseClassLoader@a9255c".  ConsoleAppender needs to be 
loaded by either the same classloader used to load the Appender class or a 
child of that classloader.  It appears that log4j is using attempting to 
use a  parent of the classloader used to load Appender here.

What is the motivation is for using this Thread Context Classloader by 
default anyway?

I haven't worked much with this Thread Context Classloader much, but 
accourding to the docs, getContextClassLoader() will return the the 
ClassLoader context of the parent Thread if setContextClassLoader() is not 
used.  In fact, you can see this behavior by clicking the "run" button 
with the junit swing TestRunner.  The Appender class is always loaded from 
a NEW classloader, but the ConsoleAppender class is always attempted to be 
loaded by the SAME classloader each time - i.e. the ConsoleAppender is 
being loaded by this one Thread Context Classloader that knows nothing 
about new classloaders being created by junit.

Does this make sense to anyone?


It certainly does. It very much looks like you have the log4j.jar loaded 
twice by two distinct class loaders. As the log4j warning messages 
indicate, most probably you have log4j.jar in the classpath and at the same 
time log4j.jar is available to the junit.runner.TestCaseClassLoader .

According to the Java Language Spec two classes loaded by different class 
loaders, even if bit-wise identical, are considered incompatible.


--
Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Quick question on "the scope of Log4j's configuration settings"

[Lutz Michael]

Thanks in advance for any feedback.

My organization has a non-negotiable requirement to support many customers
on a given machine.  The J2EE servlet standard has rules specifying how each
web application in a servlet container owns its own class loader.  Thus, in
the same JVM process space, we are able to support multiple customers
running multiple versions of our code.

The question deals with Log4j's ability to be configured differently for
such customers, given the fact that they may be running in the same JVM
process space, but under different web applications.

So the question is - when Log4j is configured, what is the scope of the
configuration settings?  I've looked through the documentation (which is
excellent) and couldn't find this answer (maybe the answer is implied and I
just didn't get it).  Is the scope the entire JVM process space, thus
disallowing our scenario?  ... or following Ceki's servlet-based
configuration pattern (http://jakarta.apache.org/log4j/docs/manual.html), in
a servlet world (and if we include the Log4j jar's in each Web application),
can we isolate the effect of configuring Log4j to distinct Web applications
even though they run in the same JVM space?

I'm thinking the question really comes down to - (a) how does Log4j
internally maintain config settings (statics?), and (b) what is the effect
from a scope perspective of this approach - e.g. can we isolate down to the
web application level inside a single JVM space and servlet container.

This question is very important to my organization, thanks for your time.

Mike

---
This message and any included attachments are from Siemens Medical Solutions 
Health Services Corporation and are intended only for the addressee(s).  
The information contained herein may include trade secrets or privileged or 
otherwise confidential information.  Unauthorized review, forwarding, printing, 
copying, distributing, or using such information is strictly prohibited and may 
be unlawful.  If you received this message in error, or have reason to believe 
you are not authorized to receive it, please promptly delete this message and 
notify the sender by e-mail with a copy to [EMAIL PROTECTED]  Thank you

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Quick question on "the scope of Log4j's configuration settings"

[Ebersole, Steven]

The configs are maintained per-LoggerRepository.  The scope of this depends
on the RepositorySelector implementation that you are using.  The default
selector uses classloaders as its scoping mechanism, and thus does work with
the way you want in servlet containers which use seperate classloaders for
each defined web app;ication.



|-Original Message-
|From: Lutz Michael [mailto:[EMAIL PROTECTED]]
|Sent: Friday, January 10, 2003 8:54 AM
|To: 'Log4J Users List'
|Subject: Quick question on "the scope of Log4j's 
|configuration settings"
|
|
|
|
|Thanks in advance for any feedback.
|
|My organization has a non-negotiable requirement to 
|support many customers
|on a given machine.  The J2EE servlet standard has rules 
|specifying how each
|web application in a servlet container owns its own class 
|loader.  Thus, in
|the same JVM process space, we are able to support 
|multiple customers
|running multiple versions of our code.
|
|The question deals with Log4j's ability to be configured 
|differently for
|such customers, given the fact that they may be running in 
|the same JVM
|process space, but under different web applications.
|
|So the question is - when Log4j is configured, what is the 
|scope of the
|configuration settings?  I've looked through the 
|documentation (which is
|excellent) and couldn't find this answer (maybe the answer 
|is implied and I
|just didn't get it).  Is the scope the entire JVM process 
|space, thus
|disallowing our scenario?  ... or following Ceki's servlet-based
|configuration pattern 
|(http://jakarta.apache.org/log4j/docs/manual.html), in
|a servlet world (and if we include the Log4j jar's in each 
|Web application),
|can we isolate the effect of configuring Log4j to distinct 
|Web applications
|even though they run in the same JVM space?
|
|I'm thinking the question really comes down to - (a) how does Log4j
|internally maintain config settings (statics?), and (b) 
|what is the effect
|from a scope perspective of this approach - e.g. can we 
|isolate down to the
|web application level inside a single JVM space and 
|servlet container.
|
|This question is very important to my organization, thanks 
|for your time.
|
|Mike
|
|---
|
|This message and any included attachments are from Siemens 
|Medical Solutions 
|Health Services Corporation and are intended only for the 
|addressee(s).  
|The information contained herein may include trade secrets 
|or privileged or 
|otherwise confidential information.  Unauthorized review, 
|forwarding, printing, 
|copying, distributing, or using such information is 
|strictly prohibited and may 
|be unlawful.  If you received this message in error, or 
|have reason to believe 
|you are not authorized to receive it, please promptly 
|delete this message and 
|notify the sender by e-mail with a copy to 
|[EMAIL PROTECTED]  Thank you
|
|--
|To unsubscribe, e-mail:   

For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Quick question on "the scope of Log4j's configuration setting s"

[Ceki Gülcü]

At 08:59 10.01.2003 -0600, Ebersole, Steven wrote:

The configs are maintained per-LoggerRepository.  The scope of this depends
on the RepositorySelector implementation that you are using.


Exactly.


The default
selector uses classloaders as its scoping mechanism, and thus does work with
the way you want in servlet containers which use seperate classloaders for
each defined web app;ication.


The default RepositorySelector simply returns the default repository. It is 
insensitive to classloaders.

Please also see http://qos.ch/logging/sc.html


--
Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Quick question on "the scope of Log4j's configuration settings"

[Jacob Kjome]

Hello Lutz,

Putting log4j.jar inside WEB-INF/lib of each webapp solves this issue
immediately.  The other comments about repository selectors are true
and valid, but, if you want to simplify things, simply putting a
separate copy of log4j.jar in the WEB-INF/lib of every webapp you
deploy will provide for a separate logger configuration environment
per/webapp.

Now, if you want all apps to share log4j, you can use something like
the ContextClassLoaderSelector which is included in the CVS for
Log4j-1.3.  When you start up your app, make your configuration
servlet or servlet context listener call
ContextClassLoaderSelector.doIdempotentInitialization() before you
call any configure() method.

Now your app will be using its own logger repository keyed upon the
current webapp's classloader.  This provides the same sort of separate
logger configuration envionment that the first case (above) provides for.

Jake


Friday, January 10, 2003, 8:54:06 AM, you wrote:



LM> Thanks in advance for any feedback.

LM> My organization has a non-negotiable requirement to support many customers
LM> on a given machine.  The J2EE servlet standard has rules specifying how each
LM> web application in a servlet container owns its own class loader.  Thus, in
LM> the same JVM process space, we are able to support multiple customers
LM> running multiple versions of our code.

LM> The question deals with Log4j's ability to be configured differently for
LM> such customers, given the fact that they may be running in the same JVM
LM> process space, but under different web applications.

LM> So the question is - when Log4j is configured, what is the scope of the
LM> configuration settings?  I've looked through the documentation (which is
LM> excellent) and couldn't find this answer (maybe the answer is implied and I
LM> just didn't get it).  Is the scope the entire JVM process space, thus
LM> disallowing our scenario?  ... or following Ceki's servlet-based
LM> configuration pattern (http://jakarta.apache.org/log4j/docs/manual.html), in
LM> a servlet world (and if we include the Log4j jar's in each Web application),
LM> can we isolate the effect of configuring Log4j to distinct Web applications
LM> even though they run in the same JVM space?

LM> I'm thinking the question really comes down to - (a) how does Log4j
LM> internally maintain config settings (statics?), and (b) what is the effect
LM> from a scope perspective of this approach - e.g. can we isolate down to the
LM> web application level inside a single JVM space and servlet container.

LM> This question is very important to my organization, thanks for your time.

LM> Mike

LM> ---
LM> This message and any included attachments are from Siemens Medical Solutions 
LM> Health Services Corporation and are intended only for the addressee(s).  
LM> The information contained herein may include trade secrets or privileged or 
LM> otherwise confidential information.  Unauthorized review, forwarding, printing, 
LM> copying, distributing, or using such information is strictly prohibited and may 
LM> be unlawful.  If you received this message in error, or have reason to believe 
LM> you are not authorized to receive it, please promptly delete this message and 
LM> notify the sender by e-mail with a copy to [EMAIL PROTECTED]  Thank you

LM> --
LM> To unsubscribe, e-mail:   
LM> For additional commands, e-mail: 



-- 
Best regards,
 Jacobmailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Problem with Junit swing TestRunner and log4j 1.2.7

[Gary Clayburg]

Ceki Gülcü wrote:


At 05:23 10.01.2003 -0700, you wrote:


I'm running into a problem with log4j configuration when running 
junit tests from the junit.swingui.TestRunner class.
Here is the error message I get to the console:

log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not 
assignable to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [junit.runner.TestCaseClassLoader@a9255c] whereas object 
of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by 
[sun.misc.Launcher$AppClassLoader@12f6684].
log4j:ERROR Could not instantiate appender named "A1".
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not 
assignable to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [junit.runner.TestCaseClassLoader@a9255c] whereas object 
of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by 
[sun.misc.Launcher$AppClassLoader@12f6684].
log4j:ERROR Could not instantiate appender named "A1".
log4j:WARN No appenders could be found for logger (TestOmaha).
log4j:WARN Please initialize the log4j system properly.

These errors go away completely  if I specify -Dlog4j.ignoreTCL on 
the command line like this:

java -Dlog4j.ignoreTCL junit.swingui.TestRunner

This, of course, causes log4j to use Class.forName() to load 
org.apache.log4j.ConsoleAppender.

The junit swing test runner has a default option to reload classes 
everytime you click the "run" button.  This is a good thing so you 
can avoid restarting the gui.  The problem with log4j though, is that 
this is causing log4j to load the classes "org.apache.log4j.Appender" 
and "org.apache.log4j.ConsoleAppender" with different classloaders as 
seen in the error message.  The Appender class seems to be loaded as 
a regular java class (probably via new), but the ConsoleAppender is 
being loaded by this special Thread Context Classloader.  This 
Appender class is being loaded via this special junit class loader, 
"junit.runner.TestCaseClassLoader@a9255c".  ConsoleAppender needs to 
be loaded by either the same classloader used to load the Appender 
class or a child of that classloader.  It appears that log4j is using 
attempting to use a  parent of the classloader used to load Appender 
here.

What is the motivation is for using this Thread Context Classloader 
by default anyway?

I haven't worked much with this Thread Context Classloader much, but 
accourding to the docs, getContextClassLoader() will return the the 
ClassLoader context of the parent Thread if setContextClassLoader() 
is not used.  In fact, you can see this behavior by clicking the 
"run" button with the junit swing TestRunner.  The Appender class is 
always loaded from a NEW classloader, but the ConsoleAppender class 
is always attempted to be loaded by the SAME classloader each time - 
i.e. the ConsoleAppender is being loaded by this one Thread Context 
Classloader that knows nothing about new classloaders being created 
by junit.

Does this make sense to anyone?



It certainly does. It very much looks like you have the log4j.jar 
loaded twice by two distinct class loaders. As the log4j warning 
messages indicate, most probably you have log4j.jar in the classpath 
and at the same time log4j.jar is available to the 
junit.runner.TestCaseClassLoader .

According to the Java Language Spec two classes loaded by different 
class loaders, even if bit-wise identical, are considered incompatible.


--
Ceki 

Thanks for your quick reply.  Also, thanks for creating and maintaining 
a great logging tool!

I checked my classpath and I am only using one log4j.jar file.  But even 
if there were two jar files on the classpath, that wouldn't cause this 
problem.  The problem lies in how two different log4j configuration 
classes are loaded, namely org.apache.log4j.Appender and 
org.apache.log4j.ConsoleAppender.  These classes are most definitely 
being loaded by different classloaders, as is evident in the error 
message.  

Here is what the Junit Swing TestRunner is doing.  Every time you click 
the "Run" button, it create a new classloader and reloads all classes 
used for the test suite.  This also includes log4j classes, since they 
are used in the test classes as well as the classes under test.  This 
new classloader is the classloader that is evidently responsible for 
loading the class org.apache.log4j.Appender.  This is fine and what is 
intended with the Junit Swing TestRunner.  The problem occurs when log4j 
is configuring itself from the log4j.properties configuration file. 
Since this properties file has classnames in it, log4j must use 
Class.forName() or some equivalent mechanism to load log4j configuration 
classes based on the String representation of the class name.  But, for 
this to work, log4j MUST use the same classloader as was used for 
org.apache.log4j.Appender OR a child classloader.  This is not happening 
in this case.  

Re: Problem with Junit swing TestRunner and log4j 1.2.7

[Ceki Gülcü]

At 12:08 10.01.2003 -0700, Gary Clayburg wrote:

Thanks for your quick reply.  Also, thanks for creating and maintaining a 
great logging tool!

You are welcome.


I checked my classpath and I am only using one log4j.jar file.  But even 
if there were two jar files on the classpath, that wouldn't cause this 
problem.  The problem lies in how two different log4j configuration 
classes are loaded, namely org.apache.log4j.Appender and 
org.apache.log4j.ConsoleAppender.  These classes are most definitely being 
loaded by different classloaders, as is evident in the error message.

There is a misunderstanding here. I did not ask whether you had
log4j.jar multiple times on the classpath. I asked whether you had
log4j.jar in the classpath *and* also had log4j.jar available
*directly* to the junit.runner.TestCaseClassLoader.

Which version of Junit is this? Is there any documentation on the
class loading model of Junit?

As for your question why log4j uses the TCL, the answer is that for
the J2EE platform using the TCL is less problematic than using
Class.forName even if both are ultimately problematic. The TCL is the
lesser evil.

--
Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Problem with Junit swing TestRunner and log4j 1.2.7

[Gary Clayburg]

Ceki Gülcü wrote:


At 12:08 10.01.2003 -0700, Gary Clayburg wrote:


Thanks for your quick reply.  Also, thanks for creating and 
maintaining a great logging tool!


You are welcome.


I checked my classpath and I am only using one log4j.jar file.  But 
even if there were two jar files on the classpath, that wouldn't 
cause this problem.  The problem lies in how two different log4j 
configuration classes are loaded, namely org.apache.log4j.Appender 
and org.apache.log4j.ConsoleAppender.  These classes are most 
definitely being loaded by different classloaders, as is evident in 
the error message.


There is a misunderstanding here. I did not ask whether you had
log4j.jar multiple times on the classpath. I asked whether you had
log4j.jar in the classpath *and* also had log4j.jar available
*directly* to the junit.runner.TestCaseClassLoader.

Which version of Junit is this? Is there any documentation on the
class loading model of Junit?

As for your question why log4j uses the TCL, the answer is that for
the J2EE platform using the TCL is less problematic than using
Class.forName even if both are ultimately problematic. The TCL is the
lesser evil.

--
Ceki



The version of Junit I am using is 3.8.1, which is the latest.  The 
Junit classloader is basically a custom classloader that loads classes 
from the same place as the system classloader, which is ultimately the 
$CLASSPATH.  So basically, because of the design of this particular 
classloader, log4j classes are capable of being loaded by either 
classloader - which of course is part of the problem.


But after digging further, I noticed in the source of for Junit, they 
never call Thread.currentThread().setContextClassLoader(loader). 
Without this being set, log4j can only use the default loader for this 
thread, which fails.  In fact, by adding this line to the 
junit.runner.TestCaseClassLoader constructor, all the problems go away:

   /**
* Constructs a TestCaseLoader. It scans the class path
* and the excluded package paths
*/
   public TestCaseClassLoader() {
   this(System.getProperty("java.class.path"));
   System.out.println("creating new TestCaseClassLoader");
   Thread.currentThread().setContextClassLoader(this);
   }

The orignial constructor did not have the setContextClassLoader() method.


So I guess the question is, should log4j assume that frameworks such as 
junit call setContextClassLoader() when they create new classloaders? 
Or should log4j itself attempt to use the same classloader as was used 
for the org.apache.log4j.Appender class?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Problem with Junit swing TestRunner and log4j 1.2.7

[Ceki Gülcü]

At 13:21 10.01.2003 -0700, Gary Clayburg wrote:


The version of Junit I am using is 3.8.1, which is the latest.  The Junit 
classloader is basically a custom classloader that loads classes from the 
same place as the system classloader, which is ultimately the 
$CLASSPATH.  So basically, because of the design of this particular 
classloader, log4j classes are capable of being loaded by either 
classloader - which of course is part of the problem.


But after digging further, I noticed in the source of for Junit, they 
never call Thread.currentThread().setContextClassLoader(loader). Without 
this being set, log4j can only use the default loader for this thread, 
which fails.  In fact, by adding this line to the 
junit.runner.TestCaseClassLoader constructor, all the problems go away:

   /**
* Constructs a TestCaseLoader. It scans the class path
* and the excluded package paths
*/
   public TestCaseClassLoader() {
   this(System.getProperty("java.class.path"));
   System.out.println("creating new TestCaseClassLoader");
   Thread.currentThread().setContextClassLoader(this);
   }

The orignial constructor did not have the setContextClassLoader() method.

Good call!

You can suggest this as an enhancement to the Junit developers. I'd be
quite interested in their response.



So I guess the question is, should log4j assume that frameworks such as 
junit call setContextClassLoader() when they create new classloaders? Or 
should log4j itself attempt to use the same classloader as was used for 
the org.apache.log4j.Appender class?

In principle, log4j strives to be as stupid as it can be, and proudly
so. In particular, log4j does not try to compensate for bugs or user
misconfiguration. The stupidity principle is essential for code that
needs to be bug free. Otherwise, who would use buggy code intended to
identify bugs in one's own application?

See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9305

In particular I wrote:

   More generally, if log4j-XX.jar is available to both the context class
   loader as well as to the class loader that loaded the code currently
   being executed, then a log4j component (e.g. an appender) may be
   loaded by the context class loader such that it is incompatible with
   the log4j classes loaded by the class loader that loaded the code
   currently being executed.

   How far fetched is this scenario? Well, I am almost convinced that
   someone will come up with a case where it looks perfectly legitimate.

After reading the TestCaseClassLoader code and the question 4.8 from
the JUnit FAQ (http://junit.sourceforge.net/doc/faq/faq.htm#running_8),
the reasons for the incident are clear.

The solution is to set log4j.ignoreTCL to false, or to correctly set
the TCL to the TestCaseClassLoader (as you have done) or add
org.apache.log4j.* the excluded.properties file in junit.jar.


In summary, class loaders are just bottomless pits.


--
Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Using Log4j with Weblogic 7.0

[Madhav Inamti]

I have been using Log4j with J2EE Reference Implementation and Websphere.
Works pretty good with the J2EE connector I am working with. 

 

I recently started trying the connector on WebLogic and looks like log4j is
not recognizing any appenders. 

 

I get a 

 

log4j:WARN No appenders could be found for logger (com.m.connecto

r.spi.CManagedConnection).

log4j:WARN Please initialize the log4j system properly.

 

Message on the Weblogic server console. Looks like it is not getting the
correct log4j.properties file

 

I have the RAR file which has the connector class and the log4j.properties
file is inside the connector class jar file

 

RAR contains connector JAR + other JAR files. 

 

Connector JAR contains log4j.properties. 

 

Has anybody experienced a similar problem ?

 

Thanks in advance,

 

Madhav

Re: Problem with Junit swing TestRunner and log4j 1.2.7

[Gary Clayburg]

Ceki Gülcü wrote:


At 13:21 10.01.2003 -0700, Gary Clayburg wrote:


The version of Junit I am using is 3.8.1, which is the latest.  The 
Junit classloader is basically a custom classloader that loads 
classes from the same place as the system classloader, which is 
ultimately the $CLASSPATH.  So basically, because of the design of 
this particular classloader, log4j classes are capable of being 
loaded by either classloader - which of course is part of the problem.


But after digging further, I noticed in the source of for Junit, they 
never call Thread.currentThread().setContextClassLoader(loader). 
Without this being set, log4j can only use the default loader for 
this thread, which fails.  In fact, by adding this line to the 
junit.runner.TestCaseClassLoader constructor, all the problems go away:

   /**
* Constructs a TestCaseLoader. It scans the class path
* and the excluded package paths
*/
   public TestCaseClassLoader() {
   this(System.getProperty("java.class.path"));
   System.out.println("creating new TestCaseClassLoader");
   Thread.currentThread().setContextClassLoader(this);
   }

The orignial constructor did not have the setContextClassLoader() 
method.


Good call!

You can suggest this as an enhancement to the Junit developers. I'd be
quite interested in their response.



So I guess the question is, should log4j assume that frameworks such 
as junit call setContextClassLoader() when they create new 
classloaders? Or should log4j itself attempt to use the same 
classloader as was used for the org.apache.log4j.Appender class?


In principle, log4j strives to be as stupid as it can be, and proudly
so. In particular, log4j does not try to compensate for bugs or user
misconfiguration. The stupidity principle is essential for code that
needs to be bug free. Otherwise, who would use buggy code intended to
identify bugs in one's own application?

See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9305

In particular I wrote:

   More generally, if log4j-XX.jar is available to both the context class
   loader as well as to the class loader that loaded the code currently
   being executed, then a log4j component (e.g. an appender) may be
   loaded by the context class loader such that it is incompatible with
   the log4j classes loaded by the class loader that loaded the code
   currently being executed.

   How far fetched is this scenario? Well, I am almost convinced that
   someone will come up with a case where it looks perfectly legitimate.

After reading the TestCaseClassLoader code and the question 4.8 from
the JUnit FAQ (http://junit.sourceforge.net/doc/faq/faq.htm#running_8),
the reasons for the incident are clear.

The solution is to set log4j.ignoreTCL to false, or to correctly set
the TCL to the TestCaseClassLoader (as you have done) or add
org.apache.log4j.* the excluded.properties file in junit.jar.


In summary, class loaders are just bottomless pits.


Well, I am writing a TestCase now for TestCaseClassLoader and will 
submit it along with my modified TestCaseClassLoader and see what they say.

I'm still wondering though, if there is a another solution to the 
problem.  Can't log4j ensure that all of it's configuration classes are 
loaded by the same classloader?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

IPlanet

[David You]

Hi I am using IPlanet. I notice a problem
If I create put my log4j config file in the running directory, and read it
from there, the log4j works fine.
But if I put the config file in the classpath, and load it from there. The
log4j will not generate anything...
Any idea?

thanks
David


--
To unsubscribe, e-mail:   
For additional commands, e-mail: