You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jason Novotny <no...@aei.mpg.de> on 2004/06/23 19:13:14 UTC

log4j and a web application framework

Hi all,

    First off sorry for writing a mail that I'm sure has been asked many 
times before-- I read various documentation and am still at a loss for 
the most elegant solution to my problem...
   
    I have a web application framework that is normally installed in 
Tomcat. I have a few jars that are placed in shared/lib of the container 
as well as jars that are placed in individual webapps. Currently I have 
my own wrapper class that exists in the jar file in shared/lib and uses 
the following to use the log4j.properties file that is also packaged in 
the shared/lib jar file:

static {
        URL propsURL = 
SportletLog.class.getResource("/gridsphere/log4j.properties");
        PropertyConfigurator.configure(propsURL);
    }

This seemed to work ok generally, although a user has tried integrating 
with JBoss and discovered that our code was hijacking the JBoss logging 
causing no JBoss messages to log. basically I'm wondering what the best 
strategy is to satisfy the following requirements:

1) Core framework classes that exist in shared/lib are logged

2) Classes that exist in individual webapps are logged

3) Other webapps that exist outside are framework do whatever they want 
and our logging does not step on their toes in anyway.

4) Other classes as part of the servlet container do whatever they want 
and we do not hijack their logging.

    Thanks very much, Jason






---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: log4j and a web application framework

Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:

> Hi Jake,
> 
> For your information, the nagoya wiki is deprecated. Please refer to
> 
>    http://wiki.apache.org/logging-log4j
> 
> instead. Thank you.
> 

Thanks for letting me know.  I updated the page with proper links as well.

http://wiki.apache.org/logging-log4j/AppContainerLogging

Jake


> At 06:28 AM 6/24/2004, Jacob Kjome wrote:
> >You want a repository selector.  See..
>
>http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging
> >
> >Note that a repository selector can also be set via a system property,
> >although i can't remember the property off the top of my head.  It should
> >be in the docs or maybe someone else can provide it in a follow-up email.
> >
> >Jake
> >
> >At 07:13 PM 6/23/2004 +0200, you wrote:
> >
> >>Hi all,
> >>
> >>    First off sorry for writing a mail that I'm sure has been asked many
> >> times before-- I read various documentation and am still at a loss for
> >> the most elegant solution to my problem...
> >>
> >>    I have a web application framework that is normally installed in
> >> Tomcat. I have a few jars that are placed in shared/lib of the container
> >> as well as jars that are placed in individual webapps. Currently I have
> >> my own wrapper class that exists in the jar file in shared/lib and uses
> >> the following to use the log4j.properties file that is also packaged in
> >> the shared/lib jar file:
> >>
> >>static {
> >>        URL propsURL =
> >> SportletLog.class.getResource("/gridsphere/log4j.properties");
> >>        PropertyConfigurator.configure(propsURL);
> >>    }
> >>
> >>This seemed to work ok generally, although a user has tried integrating
> >>with JBoss and discovered that our code was hijacking the JBoss logging
> >>causing no JBoss messages to log. basically I'm wondering what the best
> >>strategy is to satisfy the following requirements:
> >>
> >>1) Core framework classes that exist in shared/lib are logged
> >>
> >>2) Classes that exist in individual webapps are logged
> >>
> >>3) Other webapps that exist outside are framework do whatever they want
> >>and our logging does not step on their toes in anyway.
> >>
> >>4) Other classes as part of the servlet container do whatever they want
> >>and we do not hijack their logging.
> >>
> >>    Thanks very much, Jason
> >>
> >>
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-user-help@logging.apache.org
> 
> --
> Ceki Gülcü
> 
>       For log4j documentation consider "The complete log4j manual"
>       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: log4j and a web application framework

Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Jake,

For your information, the nagoya wiki is deprecated. Please refer to

   http://wiki.apache.org/logging-log4j

instead. Thank you.

At 06:28 AM 6/24/2004, Jacob Kjome wrote:
>You want a repository selector.  See..
>http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging
>
>Note that a repository selector can also be set via a system property, 
>although i can't remember the property off the top of my head.  It should 
>be in the docs or maybe someone else can provide it in a follow-up email.
>
>Jake
>
>At 07:13 PM 6/23/2004 +0200, you wrote:
>
>>Hi all,
>>
>>    First off sorry for writing a mail that I'm sure has been asked many 
>> times before-- I read various documentation and am still at a loss for 
>> the most elegant solution to my problem...
>>
>>    I have a web application framework that is normally installed in 
>> Tomcat. I have a few jars that are placed in shared/lib of the container 
>> as well as jars that are placed in individual webapps. Currently I have 
>> my own wrapper class that exists in the jar file in shared/lib and uses 
>> the following to use the log4j.properties file that is also packaged in 
>> the shared/lib jar file:
>>
>>static {
>>        URL propsURL = 
>> SportletLog.class.getResource("/gridsphere/log4j.properties");
>>        PropertyConfigurator.configure(propsURL);
>>    }
>>
>>This seemed to work ok generally, although a user has tried integrating 
>>with JBoss and discovered that our code was hijacking the JBoss logging 
>>causing no JBoss messages to log. basically I'm wondering what the best 
>>strategy is to satisfy the following requirements:
>>
>>1) Core framework classes that exist in shared/lib are logged
>>
>>2) Classes that exist in individual webapps are logged
>>
>>3) Other webapps that exist outside are framework do whatever they want 
>>and our logging does not step on their toes in anyway.
>>
>>4) Other classes as part of the servlet container do whatever they want 
>>and we do not hijack their logging.
>>
>>    Thanks very much, Jason
>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: log4j and a web application framework

Posted by Jacob Kjome <ho...@visi.com>.
You want a repository selector.  See..
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging

Note that a repository selector can also be set via a system property, 
although i can't remember the property off the top of my head.  It should 
be in the docs or maybe someone else can provide it in a follow-up email.

Jake

At 07:13 PM 6/23/2004 +0200, you wrote:

>Hi all,
>
>    First off sorry for writing a mail that I'm sure has been asked many 
> times before-- I read various documentation and am still at a loss for 
> the most elegant solution to my problem...
>
>    I have a web application framework that is normally installed in 
> Tomcat. I have a few jars that are placed in shared/lib of the container 
> as well as jars that are placed in individual webapps. Currently I have 
> my own wrapper class that exists in the jar file in shared/lib and uses 
> the following to use the log4j.properties file that is also packaged in 
> the shared/lib jar file:
>
>static {
>        URL propsURL = 
> SportletLog.class.getResource("/gridsphere/log4j.properties");
>        PropertyConfigurator.configure(propsURL);
>    }
>
>This seemed to work ok generally, although a user has tried integrating 
>with JBoss and discovered that our code was hijacking the JBoss logging 
>causing no JBoss messages to log. basically I'm wondering what the best 
>strategy is to satisfy the following requirements:
>
>1) Core framework classes that exist in shared/lib are logged
>
>2) Classes that exist in individual webapps are logged
>
>3) Other webapps that exist outside are framework do whatever they want 
>and our logging does not step on their toes in anyway.
>
>4) Other classes as part of the servlet container do whatever they want 
>and we do not hijack their logging.
>
>    Thanks very much, Jason
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org