Stopping root category from logging child categories for DEBUG messages only

[A Ir]

Stopping root category/logger from logging child categories/loggers for 
DEBUG messages only.


My question is how to stop DEBUG logging message from being visible above 
certain logger.

Let say, loggers are

a DEBUG to be directed into a common-log
a.b   DEBUG to be directed into a common-log
a.b.c DEBUG to be directed into a logA
a.b.c.d   DEBUG to be directed into a logA
a.b.c.e   DEBUG to be directed into a logA
a.i   DEBUG to be directed into a common-log
a.i.j DEBUG to be directed into a common-log
a.i.j.k   DEBUG to be directed into a common-log



I would want to log all DEBUG messages from a.b.c (and it’s descendants) 
into a separate from everything else log. I.e.,

- Logging for all messages (but DEBUG from ” a.b.c”) works as always.
- DEBUG messages from a.b.c and it’s descendants to be directed through 
a.b.c's appender, and should never be visible outside of a.b.c.


Thanks,

Alex

PS. Logger.setAdditivity() works for all levels. I would need to

setAdditivity(false)

for Level.DEBUG only.



_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Sample code example

[Fabiano Carneiro]

Hi List,

I´m using the Loj4J at a big project here in the Brazil, and I would like 
that anybody pass me a sample code example in the Internet, where I can look 
it, diferent of the examples that come with the jakarta-log4j package. I 
would like a real sample code example.

Please help me.

Fabiano Carneiro
BCP Telecomunicaoes
São Paulo - Brazil


_
Chegou o novo MSN Explorer. Instale já. É gratuito: 
http://explorer.msn.com.br


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: StaticHierarchy class?

[Shapira, Yoav]

Howdy,

>Why is saving memory not important?

Saving memory is important.  However, like Ceki said (I've verified this
using a profiler for our system), the Logger instances (even at 1 for
each class) take so much less memory than your application classes, that
their memory footprint is insignificant.

And ultimately, IMHO memory is cheap and performance (speed) matters
more than memory.  

Yoav Shapira
Millennium ChemInformatics

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: StaticHierarchy class?

[Ceki Gülcü]

At 13:04 21.06.2002 -0700, you wrote:
> >Even if the saving in the memory footprint were important (which they are
>not!)
>
>Why is saving memory not important?

I did not say saving memory was not important!

I mistyped "savings" as "saving" which apparently changed the meaning
of the sentence. What I had meant to write was:

   Even if the savings (as in economy, a reduction in expentidute) from
   in the memory footprint were important (which they are not!)...

What I mean is that the gains that you will acheive (at the cost of a
lot of work) are guaranteed to be negligible.

>Can you give me some insight into how you would configure a system that
>needs to be able to have each classes logger configurable while also being
>able to keep the total number of loggers instantiated well below n, where n
>is the total number of classes loaded in the system (and using Loggers).

Interesting problem formulation. IMHO, I think it can be solved in a
complicated and convoluted way which unfortunately I do not have
the time nor the will to expose here. Moreover, solving it would not
bring any substantial gains. Again, don't tune what you don't need to
tune.


>thanks
>scott

--
Ceki


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: StaticHierarchy class?

[Klein, Scott @ TW]

>Logger x1 = Logger.getLogger("x");
>Logger x2 = Logger.getLogger("x");
>
>Both x1 and x2 reference the exact same object.

Of course, but you lose the class level granularity for configurations.
Which is exactly what I would like to keep, and in order to do so you must
create loggers by class.

The issue is that if you have a configuration for "com.foo", then request a
logger with the class "com.foo.bar.FooBar" a new logger instance is created,
rather than using the "com.foo" logger. (just as a side note: the
interesting thing here is that it will have a configuration like "com.foo").

>Even if the saving in the memory footprint were important (which they are
not!)

Why is saving memory not important?

Can you give me some insight into how you would configure a system that
needs to be able to have each classes logger configurable while also being
able to keep the total number of loggers instantiated well below n, where n
is the total number of classes loaded in the system (and using Loggers).


thanks
scott

-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 21, 2002 12:40 PM
To: Log4J Users List
Subject: Re: StaticHierarchy class?



At 14:46 19.06.2002 -0700, Klein, Scott @ TW wrote:
>I'm full of questions/comments today...
>
>Has anyone worried about the amount of resources (primarily mem space)
>attributed to Log4J to the extent that there was a need for a
>"StaticHierarchy" whereby, if a user requests a Logger that does not exist
>it will NOT be created. Basically, they have to be listed in the config
>file.
>
>A little strict - but I was thinking a step further where if
>com.foo.bar.FooBar asks for a Logger using getLogger( this.getClass() )
>then a non-Null (or non-Root!) logger is returned iff:
>+ there is a predefined logger for com.foo.bar.FooBar
>OR
>+ there is a predefined logger for com, or com.foo, or com.foo.bar - but in
>this case the logger returned is NOT a newly instantiated one, but the
>corresponding logger to the match as if they had called getLogger(
"com.foo"
>) for example (if that makes sense).

Logger x1 = Logger.getLogger("x");
Logger x2 = Logger.getLogger("x");

Both x1 and x2 reference the exact same object.

>Basically, the constraint is that if the class does not have a logger
>defined for it, or the class is contained in a package that does not have a
>logger defined for it, or its super-packages, then the root logger is
>returned. Otherwise, the deepest logger in the hierarchy along the path to
>the requestor is returned. You lose flexibility (you can't have people
>making changes to the Logger they get), but you save resources.
>
>Not sure if all that makes sense, but my primary concern is if I have 100
>classes that ask: Logger.getLogger(this.getClass()) then I am going to be
>carrying 100 instances of Logger around (guaranteed).

Even if all your 100 classes used the root logger the gains in
the memory footprint would be negligible compared to the memory foot
print of your 100 classes.  Even if the saving in the memory footprint
were important (which they are not!)  the list of configured loggers
can change during the execution of the program but an already assigned
logger cannot shed its skin and automatically assume another identity.

>Any thoughts or comments on if/why/how this might accomplished?

Yes, one comment: don't tune what you don't need to tune.

Here is one of my favorite quotes:

   Have lots of ideas and throw away the bad ones. You aren't going to
   have good ideas unless you have lots of ideas and some sort of
   principle of selection.

   -- Linus Pauling (the only person to win two unshared Nobel Prizes)


>thanks
>s

--
Ceki


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: StaticHierarchy class?

[Ceki Gülcü]

At 14:46 19.06.2002 -0700, Klein, Scott @ TW wrote:
>I'm full of questions/comments today...
>
>Has anyone worried about the amount of resources (primarily mem space)
>attributed to Log4J to the extent that there was a need for a
>"StaticHierarchy" whereby, if a user requests a Logger that does not exist
>it will NOT be created. Basically, they have to be listed in the config
>file.
>
>A little strict - but I was thinking a step further where if
>com.foo.bar.FooBar asks for a Logger using getLogger( this.getClass() )
>then a non-Null (or non-Root!) logger is returned iff:
>+ there is a predefined logger for com.foo.bar.FooBar
>OR
>+ there is a predefined logger for com, or com.foo, or com.foo.bar - but in
>this case the logger returned is NOT a newly instantiated one, but the
>corresponding logger to the match as if they had called getLogger( "com.foo"
>) for example (if that makes sense).

Logger x1 = Logger.getLogger("x");
Logger x2 = Logger.getLogger("x");

Both x1 and x2 reference the exact same object.

>Basically, the constraint is that if the class does not have a logger
>defined for it, or the class is contained in a package that does not have a
>logger defined for it, or its super-packages, then the root logger is
>returned. Otherwise, the deepest logger in the hierarchy along the path to
>the requestor is returned. You lose flexibility (you can't have people
>making changes to the Logger they get), but you save resources.
>
>Not sure if all that makes sense, but my primary concern is if I have 100
>classes that ask: Logger.getLogger(this.getClass()) then I am going to be
>carrying 100 instances of Logger around (guaranteed).

Even if all your 100 classes used the root logger the gains in
the memory footprint would be negligible compared to the memory foot
print of your 100 classes.  Even if the saving in the memory footprint
were important (which they are not!)  the list of configured loggers
can change during the execution of the program but an already assigned
logger cannot shed its skin and automatically assume another identity.

>Any thoughts or comments on if/why/how this might accomplished?

Yes, one comment: don't tune what you don't need to tune.

Here is one of my favorite quotes:

   Have lots of ideas and throw away the bad ones. You aren't going to
   have good ideas unless you have lots of ideas and some sort of
   principle of selection.

   -- Linus Pauling (the only person to win two unshared Nobel Prizes)


>thanks
>s

--
Ceki


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: ClassCastException in 1.2.4

[Edward Q. Bridges]

i'm sorry but my last response was not entirely clear.

it *also* worked with 1.2.4 (which is why i mentioned that i did not change from 
Category to Logger).
because of time constraints i did not push the testing very far.  if you like, i will 
try later today or
early next week to do a complete switch to see if it makes a difference.

cheers
--e--



On Fri, 21 Jun 2002 01:30:44 +0200, Ceki Gülcü wrote:

>
>
> Whether you use Category or Logger is not consequential. The fact that
> 1.2.1 works for you confirms my suspicions about multiple copies of
> log4j.jar available to more than one classloader.
>
> At 19:13 20.06.2002 -0400, Edward Q. Bridges wrote:
> >i've switched to htat, and indeed did not get any errors.
> >
> >however, i only changed the calls to assert() to assertLog() since there were
> >many and my time was pressed, and that allowed for things to compile.  i
> >did not
> >change the global instance to Logger from Category.
> >
> >if you think it's important to do that change as well for the test, let me
> >know.
> >i will do my best, but i'm under a lot of pressure to fix other things
> >right now
> >. . . 1.1.3 works, so the general consensus here is "don't mess with it."
> >
> >hope this helps
> >
> >best regards
> >--e--
> >
> >
> >
> >On Fri, 21 Jun 2002 00:08:50 +0200, Ceki Gülcü wrote:
> >
> > >
> > > The ClassCastException of RollingFileAppender to an Appender makes it
> > > pretty clear that we are dealing with a classloader problem. One thing
> > > that changed between log4j 1.2.1 and 1.2.2 is that in the latter
> > > version log4j will use the Thread Context Classloader (TCL) to load
> > > classes. (Log4j 1.1.3 does not use the TCL either).
> > >
> > > You can download 1.2.1 at
> > >
> > >http://jakarta.apache.org/log4j/jakarta-log4j-1.2.1.tar.gz
> > >
> > > Please try to use 1.2.1 to check whether my TCL hypothesis is correct.
> > >
> > > At 17:53 20.06.2002 -0400, Edward Q. Bridges wrote:
> > > >Nope :)
> > > >
> > > >see below.
> > > >
> > > >note that ant copies log4j.jar and others from $SERVER_HOME/tslib to
> > > >$SERVER_HOME/applications/ts2/WEB-INF/lib
> > > >and then weblogic works its wonders and puts it's own special copy in
> > > >$SERVER_HOME/applications/ts2/WEB-INF/
> > > >_tmp_war_edAdmin_edAdmin_ts2/WEB-INF/lib/
> > > >
> > > >this is representative.  the jar file you see below is actually the 1.1.3
> > > >version.  i had to rollback to the
> > > >earlier version so that i could continue working.  but, i assure you i
> > did
> > > >not remove any jar files manually
> > > >from any of those places.  the only place i touch is "tslib,"  scripts
> > and
> > > >weblogic take care of the other
> > > >places.  we do no manipulation at all of /jre/lib/ext nor the classpath.
> > > >
> > > >this setup has run flawlessly with 1.1.3.  but, not with 1.2.4 (yet!).
> > > >
> > > >many thanks!
> > > >
> > > >cheers
> > > >--e--
> > > >
> > > >
> > > >
> > > >
> > > >On Thu, 20 Jun 2002 23:36:42 +0200, Ceki Gülcü wrote:
> > > >
> > > > >
> > > > > I bet you have multiple copies of log4j.jar in the classpath, 
> > WEB-LIB or
> > > > > JAVA_HOME/jre/lib/ext. Correct?
> > > > >
> > > >
> > > >
> > > >bash-2.03$ echo $CLASSPATH
> > > >/d01/bea/wlserver6.1/patch/CR058352_
> > > >
> >61sp2.jar:/d01/bea/jdk131/lib/tools.jar:/d01/bea/wlserver6.1/lib/weblogic_sp.jar
> >:/d01/bea/wlserver6.1/lib/weblog
> > > >ic.jar
> > > >bash-2.03$ ls $JAVA_HOME/jre/lib/ext
> > > >bash-2.03$ ls -la $JAVA_HOME/jre/lib/ext
> > > >total 3
> > > >drwxr-xr-x2    512 Nov 14  2001 ./
> > > >drwxr-xr-x   11   2048 Nov 14  2001 ../
> > > >bash-2.03$ ls -la $SERVER_HOME/tslib/
> > > >total 25926
> > > >drwxrwxr-x2    512 Jun 20 16:10 ./
> > > >drwxrwxr-x   16   2560 Jun 20 17:25 ../
> > > >-rwxr--r--1  20454 Dec 24 16:34 commons-
> >beanutils.jar*
> > > >-rwxr--r--1  58798 Jul 14  2001
> > > >commons-collections.jar*
> > > >-rwxr--r--1     191881 Apr 26 11:08 jaxen-full.jar*
> > > >-rw-rw-r--1     126886 Mar 25 12:57 jdom.jar
> > > >-rwxr--r--1     158892 Mar 19 15:37 log4j.jar*
> > > >-rwxr--r--1  23563 Apr 26 11:08 saxpath.jar*
> > > >-rw-r--r--1     220703 May  3 11:13 soap.jar
> > > >-rw-r--r--1   3726 Jun 18 12:21 startup.jar
> > > >-rw-r--r--1  x25665013 Mar 25 13:29 weblogic.jar
> > > >bash-2.03$ ls -la $SERVER_HOME/applications/ts2/WEB-INF/
> > > >total 18
> > > >drwxr-xr-x5    512 Jun 20 16:27 ./
> > > >drwxr-xr-x3    512 Jun 20 16:26 ../
> > > >drwxr-xr-x3    512 Jun 20 16:27
> > > >_tmp_war_edAdmin_edAdmin_ts2/
> > > >drwxr-xr-x3    512 Jun 20 16:26 classes/
> > > >drwxr-xr-x2    512 Jun 20 16:26 lib/

RE: OutOfMemoryError for AsyncAppender

[Thomas Tuft Muller]

WriterAppender and AsyncAppender both extends AppenderSkeleton, but are
otherwise unrelated. AsyncAppender can't be configured via
PropertyConfigurator. Your thread problem must stem from something else,
because no AsyncAppender will be created in your app unless you configure
its use via DOMConfigurator or instantiate it yourself.

--

Thomas


| -Original Message-
| From: vivek gupta [mailto:[EMAIL PROTECTED]]
| Sent: 21 June 2002 13:51
| To: [EMAIL PROTECTED]
| Subject: OutOfMemoryError for AsyncAppender
|
|
| hi all,
|I have a problem in using AsyncAppender. Whenever I uses
| RollingFileAppender which extends from FileAppender while inturn extends
| from WriteAppender which extends from AsyncAppender, a large number of
| threads are created and finally I got out of Memory Exception. My
| properties file is as follows:
| log4j.category.debug.com.XYZ=DEBUG, debugProcessLog
| log4j.additivity.debug.com.XYZ=false
| log4j.appender.debugProcessLog=com.XYZ.logger.RollingFileAppender
| log4j.appender.debugProcessLog.File=c:/usr/log/process_debug.log
| log4j.appender.debugProcessLog.maxFileSize=1000
| log4j.appender.debugProcessLog.maxBackupIndex=5
| log4j.appender.debugProcessLog.BufferSize=1000
| log4j.appender.debugProcessLog.Append=true
| log4j.appender.debugProcessLog.layout=org.apache.log4j.PatternLayout
| log4j.appender.debugProcessLog.layout.ConversionPattern=%d{DATE} : %-5p
| : %m%n
|
| Please help me out as early as possible.
|
| Regards
| Vivek
|



*
Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All rights reserved. 
The information supplied in this email should be treated in confidence.
No liability whatsoever is accepted for any loss or damage 
suffered as a result of accessing this message or any attachments.


This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

OutOfMemoryError for AsyncAppender

[vivek gupta]

hi all,
   I have a problem in using AsyncAppender. Whenever I uses
RollingFileAppender which extends from FileAppender while inturn extends
from WriteAppender which extends from AsyncAppender, a large number of
threads are created and finally I got out of Memory Exception. My
properties file is as follows:
log4j.category.debug.com.XYZ=DEBUG, debugProcessLog
log4j.additivity.debug.com.XYZ=false
log4j.appender.debugProcessLog=com.XYZ.logger.RollingFileAppender
log4j.appender.debugProcessLog.File=c:/usr/log/process_debug.log
log4j.appender.debugProcessLog.maxFileSize=1000
log4j.appender.debugProcessLog.maxBackupIndex=5
log4j.appender.debugProcessLog.BufferSize=1000
log4j.appender.debugProcessLog.Append=true
log4j.appender.debugProcessLog.layout=org.apache.log4j.PatternLayout
log4j.appender.debugProcessLog.layout.ConversionPattern=%d{DATE} : %-5p
: %m%n

Please help me out as early as possible.

Regards
Vivek


**Disclaimer

Information contained in this E-MAIL being proprietary to Wipro Limited is 
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying 
or dissemination of the information contained in the E-MAIL in any manner 
whatsoever is strictly prohibited.

***



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: How are people using Chainsaw/LogFactor5?

[Frissaer, Jeroen]

Thanks for not forgetting about it Mark.

Regards
Jeroen

-Original Message-
From: Mark Womack [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 20, 2002 6:29 PM
To: 'Log4J Users List'
Subject: RE: How are people using Chainsaw/LogFactor5?


I was going to point out SocketHubAppender, thank you, Michael.  I wrote and
submitted SocketHubAppender for the very reason Eric is asking about.  With
it in place, it becomes easier to "plug in" to a server and watch what it is
logging.  If you are not connected, then few to no resources are used for
the SocketHubAppender, it just sits idle.  I don't know if the same can be
said for JMSAppender or other Appenders.

Unfortunately, Chainsaw and LF5 (I need to look closer at LF5) need to be
modified to work with the SocketHubAppender.  Instead of passively accepting
connections, they need to actively initiate connections.  This has been on
my plate since Jeroen asked about it recently.  I will bite the bullet this
weekend and modify both of them to handle it.

-Mark

> -Original Message-
> From: Michael Roytman [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 20, 2002 8:07 AM
> To: 'Log4J Users List'
> Subject: RE: How are people using Chainsaw/LogFactor5?
> 
> 
> Have you looked into SocketHubAppender that's in Log4J 1.2?
> Here is exeprt form SocketHubAppender  Javadoc:
> "Acts just like SocketAppender except that instead of 
> connecting to a given
> remote log server, SocketHubAppender accepts connections from 
> the remote log
> servers as clients. It can accept more than one connection. 
> When a log event
> is received, the event is sent to the set of currently 
> connected remote log
> servers. Implemented this way it does not require any update to the
> configuration file to send data to another remote log server. 
> The remote log
> server simply connects to the host and port the 
> SocketHubAppender is running
> on."
> 
> -Original Message-
> From: Eric Pugh [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 20, 2002 3:20 AM
> To: 'Log4J Users List'
> Subject: How are people using Chainsaw/LogFactor5?
> 
> 
> Hi all,
> 
> I have three environments that I am interested in monitoring 
> via LogFactor5,
> dev, test, and production.  What is causing me problems is 
> that the current
> setup for both LF5 and CS is that the server has to know 
> where the client
> is.  Versus the client just picking the server to listen to.  
> I want to be
> able to have a single copy of LF5 on my laptop, and then be 
> able to "pick" a
> server to listen in on.  And if I want to receive events to a 
> different
> machine, I need to reconfigure my log4j.prop files and 
> restart my servers.
> 
> Is there anything out there that allows my various 
> Socketappender messages
> from dev, test, and live to be aggregated on a single server, 
> and then have
> a client connect to the single known server and listen for messages?
> Somewhat related, are there any good applet based log viewer 
> solutions that
> could be used?
> 
> Eric Pugh
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: