logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Taylor" <cstay...@pacbell.net>
Subject Re: class loading problems
Date Thu, 14 Jun 2001 17:47:47 GMT
I'll see if I can crib a suitable solution that allows us to continue using JDK 1.1 with Log4J....
if I remember correctly, JNDI had the same trouble...

-Chris
  ----- Original Message ----- 
  From: Gray Jones 
  To: LOG4J Users Mailing List 
  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 ----- 
    From: Christopher Taylor 
    To: LOG4J Users Mailing List 
    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 ----- 
      From: Christopher Taylor 
      To: LOG4J Users Mailing List 
      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 ----- 
      From: "Gray Jones" <gray@earthcars.com>
      To: "LOG4J Users Mailing List" <log4j-user@jakarta.apache.org>
      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: log4j-user-unsubscribe@jakarta.apache.org
      > For additional commands, e-mail: log4j-user-help@jakarta.apache.org
      > 

Mime
View raw message