----- Original Message -----
Sent: Thursday, June 14, 2001 6:30
AM
Subject: Re: class loading problems
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]
>
