Good analysis. How do we get this change made? Would you like to submit a
patch to the dev team, Will?

Steve Meyfroidt


> -----Original Message-----
> From: William Jaynes [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 30, 2001 7:55 PM
> To: LOG4J Users Mailing List
> Subject: Re: Tomcat problem (again)
> 
> 
> I don't feel competent to comment on your classpath explanation, but I
> do have the following empirical information.
> 
> Using log4j-1.1.1 with Tomcat 3.2.1, putting log4j.jar into 
> WEB-INF/lib
> and log4j.properties into WEB-INF/classes, the static initializer does
> not find log4j.properties. Changing DEFAULT_CONFIGURATION_FILE to
> "/log4j.properties" does not make any difference.   Move
> log4j.properties out to /tomcat/classes, which is on the tomcat
> classpath, and the static initializer finds it. This I would expect.
> Move log4j.jar out to /tomcat/lib, and again log4j.properties 
> is found.
> Move log4j.properties back to WEB-INF/classes and it isn't found.
> 
> All of the above behaviour is expected (by me) except for the first.
> Packaging log4j.jar and log4j.properties into a web application should
> result in the static initializer finding the properties file 
> in the web
> application. In the current release, this does not happen.
> 
> I trace this anomaly to the following line in Category.java
>         url = Loader.getResource(resource, Object.class);
> I believe that "Category.class" rather than "Object.class" should be
> used. ClassLoaders are organized into a hierarchy, and the one fetched
> using Object.class is at an upper level, and therefore won't 
> be able to
> "see" into a web application, each of which has its own ClassLoader.
> Using "Category.class" would at least insure that the 
> properties file is
> searched for using the same class loader as was used to load the
> log4j.jar.
> 
> If I make the change I suggest, then no matter where I put 
> log4j.jar and
> log4j.properties, the behaviour of the static initializer is 
> as I expect
> it to be.
> 
> Regards, Will
> 
> ----- Original Message -----
> From: "Fergus Gallagher" <[EMAIL PROTECTED]>
> To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> Cc: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]>
> Sent: Wednesday, May 30, 2001 12:46 PM
> Subject: Re: Tomcat problem (again)
> 
> 
> > When it comes to loading files from the classpath, note the 
> difference
> between
> >
> >          myClass.getClassLoader().getResource()
> >
> > and
> >
> >          myClass.getResource()
> >
> > The former loads wrt to the classpath root, but the latter loads wrt
> to the
> > location of the class bytecode file (typically).
> >
> > i.e., if myClass = com.acme.MyClass
> >
> >          myClass.getClassloader().getResource("abc.def") =>
> > <classpathroot>/abc.def
> >
> >          myClass.getResource("abc.def") =>
> <classpathroot>/com/acme/abc.def
> >
> > On the specific tomcat issue, if log4j.jar is in the tomcat 
> top-level
> > classpath ($TOMCAT_HOME/lib), then neither method will be able to
> locate
> > "log4j.properties" in <webapp>/WEB-INF/classes.   The top-level
> classloader
> > has no access to the private web-app classpath, unless it's given an
> > explicit handle.
> >
> > The solution is either to put log4j.jar and log4j.properties in the
> tomcat
> > classpath, OR both in the web-app.    Any log4j.jar in the tomcat
> classpath
> > will take precedence.
> >
> > Fergus
> >
> > At 17:25 30/05/2001 +0100, Steve Meyfroidt wrote:
> > >Hi,
> > >
> > >[[[A disclaimer: I've searched the archives for the 
> solution to this
> but
> > >found nothing that I like. And Bugzilla is down too, so 
> I'm sorry if
> this
> > >has been covered to death in this list.]]]
> > >
> > >I'm having trouble with init of log4j for a servlet running in
> Tomcat. log4j
> > >can't find the default config file, "log4j.properties".
> > >
> > >The reason for this appears to be that log4j looks for
> > >      static public final String DEFAULT_CONFIGURATION_FILE =
> > >"log4j.properties";
> > >by default, when it should really be looking for 
> "/log4j.properties".
> The
> > >slash prefix is significant when loading resources from the
> classpath. I
> > >think this would solve the problems that I see other 
> people have been
> > >having.
> > >
> > >Has this been discussed? Am I on the right track? Is it a 
> bug? Can I
> submit
> > >it?
> > >
> > >Regards,
> > >Steve Meyfroidt
> > >
> > 
> >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Fergus Gallagher
> > Orbis
> > http://www.orbisuk.com/
> > +44-(0)20-8742 1600
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to