I just copied my message to the log4j-dev list, asking for this change.
I have had an exchange with Ceki about this in the past. Perhaps there's
more to the problem than I know and he hasn't yet decided how to handle
it.
Regards, Will
----- Original Message -----
From: "Steve Meyfroidt" <[EMAIL PROTECTED]>
To: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Thursday, May 31, 2001 4:31 AM
Subject: RE: Tomcat problem (again)
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
