|
Chris,
I tried your suggestions and it seemed to
work. Here's what I did...
in BasicConfigurator.addRenderer ~line
112
try {
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader
== null)
{
loader =
Class.forName(renderedClassName).getClassLoader();
}
Class
renderedClass = loader.loadClass(renderedClassName);
hierarchy.rendererMap.put(renderedClass,
renderer);
}
Also I did something similar in
OptionConverter.instantiateByClassName ~line 301
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader
== null)
{
loader =
Class.forName(className).getClassLoader();
}
Class
classObj = loader.loadClass(className);
We are using jdk1.2 so I didn't have to worry about
the jdk version. It does seem like classloading is becoming a bigger
issue these days. We've been having similar types of problems with other
vendors/products.
Thanks,
Gray
----- Original Message -----
Sent: Wednesday, June 13, 2001 8:01
PM
Subject: Re: class loading problems
Oops... ignore the part about forName() on the ClassLoader... I meant loadClass().
In addition, the code would look
like:
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if (loader == null)
{
loader =
getClass().getClassLoader();
}
return loader.loadClass([class
name]);
-Chris
----- Original Message -----
Sent: Wednesday, June 13, 2001 4:45
PM
Subject: Re: class loading
problems
This is just an idea, but after looking through
the source code for the BasicConfigurator and DOMConfigurator, I noticed
that they aren't using the JDK 1.2+ construct Thread.currentThread().getContextClassLoader().forName().
I'm not a JBoss user, but from what I know
about Classloaders your Appender won't be loaded if the log4J.jar is in an ancestor
classloader. In JDK1.2 and above, Classloading goes upwards.
You can find out using a simple
loop:
for (ClassLoader klassldr =
Class.forName("org.apache.log4j.BasicConfigurator").getClassLoader();
klassldr !=
null;
klassldr
= klassldr.getParent())
System.out.println (klassldr);
for (ClassLoader klassldr =
Class.forName("com.earthcars.log.EarthcarsSMTPAppender").getClassLoader();
klassldr !=
null;
klassldr
= klassldr.getParent())
System.out.println (klassldr);
If I'm right, we probably need to put some code into Log4J where we
delegate the classloading to a stub object that gets loaded with a java
version check (if 1.1 use Class.forName, if 1.2 use
Thread.currentThread().getContextClassLoader().forName()).
-Chris
----- Original Message -----
Sent: Wednesday, June 13, 2001 2:34
PM
Subject: class loading
problems
> I am experiencing classpath/classload problems when trying to
use my own
> appender class and jboss EJB server. jboss has its
own way of dynamically
> creating the classpath during system
startup. It dynamically reads all the
> jars in a specified
directory and adds them to it's classpath. It doesn't
> export
the classpath to the classpath variable.
>
> The problem is
that our homegrown appender is included with all of our other
>
classes in the jar that is deployed by the server. When log4j attempts
to
> initialize the appender, it can't find the class even though it
is in the
> jar file along with all our other beans, etc.
>
> So does this indicate the log4j isn't getting its class loader from
the
> correct source. Or do we have to go back and re-arrange
our package
> structure and create two seperate jars. Jboss
hates it when you have
> duplicate classes in the classpath
>
>
log4j.appender.errorSMTP=com.earthcars.log.EarthcarsSMTPAppender
>
>
>
>
---------------------------------------------------------------------
>
To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
|
