At 09:23 AM 12/16/2004 -0800, you wrote:
>Hey Jake, comments below.
>
>> -Original Message-
>> From: Jacob Kjome [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, December 15, 2004 6:20 PM
>> To: Log4J Developers List
>> Subject: RE: o.a.log4j.servlet
>
Hey Jake, comments below.
> -Original Message-
> From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 15, 2004 6:20 PM
> To: Log4J Developers List
> Subject: RE: o.a.log4j.servlet
>
> At 05:39 PM 12/15/2004 -0800, you wrote:
> >>
>
At 05:39 PM 12/15/2004 -0800, you wrote:
>>
>>
>> > override="false"
>> description="location for Log4j-generated log files"/>
>>
>
>Got it. Do you think that supporting a JNDI resource is a better standard
>way to do this? I mean I still had to modify 2 configuration files
>(server.xml
Jake,
> > One thing I noticed with the default behavior in InitShutdownController
> is
> > that if you deploy using a war file, then the WEB-INF/log directory
> > typically ends up in the temp directory the container (like jboss) uses
> to
> > expand/explode the war file. Tracking down the locati
know to configure it is the context
path, such as "/Myapp" and you define the log file for your servlet context at
the appserver level.
Jake
> -Mark
>
> > -----Original Message-
> > From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 14,
OTECTED]
Subject: RE: o.a.log4j.servlet
Hi,
> Well, maybe you guys have had to solve this kind of problem before. I
want
This is a common problem, and environment-based solutions for it will break
because they're fundamentally against the spirit of the Servlet and J2EE
specs.
The main
uesday, December 14, 2004 6:52 PM
> To: Log4J Developers List
> Subject: RE: o.a.log4j.servlet
>
> At 05:10 PM 12/14/2004 -0800, you wrote:
> >Well, maybe you guys have had to solve this kind of problem before. I
> want
> >to have the log home directory in one place for
Hi,
> Well, maybe you guys have had to solve this kind of problem before. I want
This is a common problem, and environment-based solutions for it will break
because they're fundamentally against the spirit of the Servlet and J2EE specs.
The main reason these solutions will eventually break is t
out in the
sandbox. Oh, I just remembered, I have modified the sandbox locally to
work with Log4j-1.3. I'll try to check that in sometime tonight.
Jake
>-Mark
>
>-Original Message-
>From: Yoav Shapira [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, December 14, 2004 4:33
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 4:33 PM
To: Log4J Developers List
Subject: Re: o.a.log4j.servlet
Hi,
It's fairly pointless to rely on getServerInfo and
similar approaches: it's
one
of the first things security-conscious server
administrators customize or
spoof,
---
From: Yoav Shapira [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 14, 2004 4:33 PM
To: Log4J Developers List
Subject: Re: o.a.log4j.servlet
Hi,
It's fairly pointless to rely on getServerInfo and similar approaches: it's
one
of the first things security-conscious server admini
Hi,
It's fairly pointless to rely on getServerInfo and similar approaches: it's one
of the first things security-conscious server administrators customize or
spoof, as that's a recommended best practice.
Class-name-based detections (e.g. Class.forName("org.apache.catalina.foo.bar")
for Tomcat) are
Also, does anyone know if there is a way to
programmatically detect the web
container the web app is running under? I am seeing a
need to have
different behavior between JBoss and Tomcat, and I was
just wondering if
there is a standard way to detect this.
-Mark
Mark,
The ServletContext has
So, I have had the opportunity at my job to integrate and
use the o.a.log4j.servlet classes in the sandbox. And I have to say that
the initialization related classes (InitContextListener,
InitShutdownController) really rock! Many thanks to Jake for focusing on
these classes and making
14 matches
Mail list logo
