Confirm successful reading of a conf file, check if loggers and appenders were instatntiated

2007-01-18 Thread Marcel Gołuński

Hello.
I made a little research before posting here. And i didn't find any 
interesting answers.


Major question:

(from log4j wiki's FAQ - not answered 
(http://wiki.apache.org/logging-log4j/FrequentlyAskedQuestions) )
"How can I get notified of errors during configuration and then handle them? 
For example, I want to log to a file but the directory does not exist yet. I 
want to catch that configuration error, create the directory and restart 
configuration."
(from wiki's requested features 
(http://wiki.apache.org/logging-log4j/Log4jRequestedFeatures) )
"PropertyConfigurator.configure() and doConfigure() methods should return 
some sort of status to know if the loaded properties are valid."


I'm using DOMConfigurator (configureAndWatch) to read a conf file for a 
jboss webapp (log4j1.2.8, checked 1.2.14 nothing changed). I want to know if 
the reading was successful. I think that there is no exeption thrown (even 
if file does not exist, not only on validation errors).

my questions:
- Is there any way to check if the conf file was read successfully (I may 
switch to properties configuration if it is supported there)
- Is there any way to check on configureAndWatch that file was actually 
reread and configuration changes were made. (For example to attach some 
actionPerformer to log4j configureAndWatch which will be triggered when 
reading occures.) (I suppose no)?

-
Minor questions:
NOTE: I know that file appenders throw exeptions so it is easy there.

How can i determine that appenders and loggers were instantiated (created)?
my idea (not checked but i think working):
- logger
org.apache.log4j.LogManager
method: exist()

- appender (after attaching to a logger)
org.apache.log4j.Logger (exactly Category super class)
methods: isAttached(), getAppender(), getAllAppenders() (and Enumerate for 
the one im trying to check)


Is there any other way (easier, faster) to determine that loggers and 
appenders were created and attached succesfully?
Its a pity that log4j does not support exceptions, but i understand the 
"performance issue", and think that it is connected with the lack of 
exceptions.


Sorry for my English.

Best Wishes,
--
Marcel Golunski
Horus s.c. http://www.horus.com.pl 



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



Re: Logging to multiple files, per context

2007-01-18 Thread James Stauffer

Search the archive for logging to one file per thread.

On 1/18/07, Rudi <[EMAIL PROTECTED]> wrote:

Hello,

I have a hand coded server which handle multiple sessions at one time (of
course, its a server after all). Each session would be handled by dedicated
thread. It is a requirement that incoming and outgoing messages be logged on
separate files, using the session specific attribute as the context.
What i want to ask is, what's the 'official' log4j way of doing such thing
and where can i get the manual? I am pretty sure that there is at least one
such way since i encountered the term 'multiple hierarchy trees' several
times, yet couldnt found any further hint.

regards,

rudi

--
http://www.bungrudi.com/





--
James Staufferhttp://www.geocities.com/stauffer_james/
Are you good? Take the test at http://www.livingwaters.com/good/

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



Re: Confirm successful reading of a conf file, check if loggers and appenders were instatntiated

2007-01-18 Thread James Stauffer

I believe the reason that log4j configuration doesn't thow exceptions
is that normally logging isn't the core reason for the program and a
problem with logging shouldn't stop the program.

If you look through the API I believe you will find methods to obtain
attached appenders so you could verify that way (but then your code
would have to know about your config).

On 1/18/07, Marcel Gołuński <[EMAIL PROTECTED]> wrote:

Hello.
I made a little research before posting here. And i didn't find any
interesting answers.

Major question:

(from log4j wiki's FAQ - not answered
(http://wiki.apache.org/logging-log4j/FrequentlyAskedQuestions) )
"How can I get notified of errors during configuration and then handle them?
For example, I want to log to a file but the directory does not exist yet. I
want to catch that configuration error, create the directory and restart
configuration."
(from wiki's requested features
(http://wiki.apache.org/logging-log4j/Log4jRequestedFeatures) )
"PropertyConfigurator.configure() and doConfigure() methods should return
some sort of status to know if the loaded properties are valid."

I'm using DOMConfigurator (configureAndWatch) to read a conf file for a
jboss webapp (log4j1.2.8, checked 1.2.14 nothing changed). I want to know if
the reading was successful. I think that there is no exeption thrown (even
if file does not exist, not only on validation errors).
my questions:
- Is there any way to check if the conf file was read successfully (I may
switch to properties configuration if it is supported there)
- Is there any way to check on configureAndWatch that file was actually
reread and configuration changes were made. (For example to attach some
actionPerformer to log4j configureAndWatch which will be triggered when
reading occures.) (I suppose no)?
-
Minor questions:
NOTE: I know that file appenders throw exeptions so it is easy there.

How can i determine that appenders and loggers were instantiated (created)?
my idea (not checked but i think working):
- logger
org.apache.log4j.LogManager
method: exist()

- appender (after attaching to a logger)
org.apache.log4j.Logger (exactly Category super class)
methods: isAttached(), getAppender(), getAllAppenders() (and Enumerate for
the one im trying to check)

Is there any other way (easier, faster) to determine that loggers and
appenders were created and attached succesfully?
Its a pity that log4j does not support exceptions, but i understand the
"performance issue", and think that it is connected with the lack of
exceptions.

Sorry for my English.

Best Wishes,
--
Marcel Golunski
Horus s.c. http://www.horus.com.pl


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





--
James Staufferhttp://www.geocities.com/stauffer_james/
Are you good? Take the test at http://www.livingwaters.com/good/


Re: Confirm successful reading of a conf file, check if loggers and appenders were instatntiated

2007-01-18 Thread Curt Arnold



On 1/18/07, Marcel Gołuński <[EMAIL PROTECTED]> wrote:


Is there any other way (easier, faster) to determine that loggers and
appenders were created and attached succesfully?
Its a pity that log4j does not support exceptions, but i  
understand the

"performance issue", and think that it is connected with the lack of
exceptions.



On Jan 18, 2007, at 9:39 AM, James Stauffer wrote:


I believe the reason that log4j configuration doesn't thow exceptions
is that normally logging isn't the core reason for the program and a
problem with logging shouldn't stop the program.

If you look through the API I believe you will find methods to obtain
attached appenders so you could verify that way (but then your code
would have to know about your config).



My understanding is the lack of exceptions from the configurators was  
not motivated by performance concerns, but that a bad configuration  
file would not cause an otherwise working application to fail.   
Unfortunately, that design decision makes it difficult to  
programatically respond to configuration failures, like providing a  
backup configuration if the configuration file was missing.


I did start an experimental project (search for strictxml) in the  
sandbox for new XML configurator that used a stricter syntax and  
provided more feedback on the processing of the configuration.   
However, that has been dormant for a while and probably will not see  
much addition effort until log4j 2.0 development starts whenever that  
is.

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



Re: Confirm successful reading of a conf file, check if loggers and appenders were instatntiated

2007-01-18 Thread James Stauffer

Could the configure method be changed to return a boolean indicating
sucess?  If someone detected that configuration failed, would log4j be
in an undefined state so that configuring with another file might not
produce the desired results?

One way to detect config problems would be to run with -Dlog4j.debug
and capture and parse System.out info produced by log4j.

On 1/18/07, Curt Arnold <[EMAIL PROTECTED]> wrote:


> On 1/18/07, Marcel Gołuński <[EMAIL PROTECTED]> wrote:
>>
>> Is there any other way (easier, faster) to determine that loggers and
>> appenders were created and attached succesfully?
>> Its a pity that log4j does not support exceptions, but i
>> understand the
>> "performance issue", and think that it is connected with the lack of
>> exceptions.


On Jan 18, 2007, at 9:39 AM, James Stauffer wrote:

> I believe the reason that log4j configuration doesn't thow exceptions
> is that normally logging isn't the core reason for the program and a
> problem with logging shouldn't stop the program.
>
> If you look through the API I believe you will find methods to obtain
> attached appenders so you could verify that way (but then your code
> would have to know about your config).
>

My understanding is the lack of exceptions from the configurators was
not motivated by performance concerns, but that a bad configuration
file would not cause an otherwise working application to fail.
Unfortunately, that design decision makes it difficult to
programatically respond to configuration failures, like providing a
backup configuration if the configuration file was missing.

I did start an experimental project (search for strictxml) in the
sandbox for new XML configurator that used a stricter syntax and
provided more feedback on the processing of the configuration.
However, that has been dormant for a while and probably will not see
much addition effort until log4j 2.0 development starts whenever that
is.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
James Staufferhttp://www.geocities.com/stauffer_james/
Are you good? Take the test at http://www.livingwaters.com/good/


Using HTMLLayout

2007-01-18 Thread chuanjiang lo

Hi,

I am using HTMLLayout and logging into an html file.
Whenever the server restarts, it will continue logging into the same
previous html file.

I notice that the whole html header is appended into the html file again
because of the getHeader() in HTMLLayout class.
Is there anyway to avoid this? If the html file already exist, do not call
getHeader() method?

Regards


Re: Confirm successful reading of a conf file, check if loggers and appenders were instatntiated

2007-01-18 Thread Curt Arnold


On Jan 18, 2007, at 11:06 AM, James Stauffer wrote:


Could the configure method be changed to return a boolean indicating
sucess?  If someone detected that configuration failed, would log4j be
in an undefined state so that configuring with another file might not
produce the desired results?



In the strictxml project, I went out of my way to defer actually  
applying any configuration changes until processing was very likely  
to succeed, so that a parsing failure would leave the configuration  
unchanged.  The approach can fail if things that are only checked in  
the activateOptions method, but that was the best I could do without  
touching log4j itself.




One way to detect config problems would be to run with -Dlog4j.debug
and capture and parse System.out info produced by log4j.



That is useful for analysis, but isn't helpful if your program is  
trying to appropriately respond to a configuration problem.







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



RE: Logging stops after hours working

2007-01-18 Thread Cristian Jansenson
Thanks Jake.  I suspect there is a threading problem in the app that is
causing this issue.  Your clarification that is not a problem already
encountered in log4j package helps a lot.  Thanks,

Cristian Jansenson


-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 16, 2007 10:58 PM
To: Log4J Users List
Subject: RE: Logging stops after hours working


The behavior is curious.  I would guess that some other library is 
configuring Log4j on it's own.  This doesn't have to be via a config 
file.  It could be just doing it programmatically.  I take it you 
searched for both log4j.properties *and* log4j.xml.  You only 
mentioned the former, so I thought I'd make sure.  This one's a tough 
nut to crack.  I'm not sure I can say anything other than good luck 
finding the source of the problem!

BTW, the printing you see is being printed by LogLog, which is Log4j 
bootstrap logger.  Log4j 1.3 uses standard Log4j logging to log its 
own messages.  Log4j 1.2.xx uses LogLog to log its own messages.


Jake

At 07:59 PM 1/16/2007, you wrote:
 >More to add to this case:
 >
 >- We are not using any special classloader, and there is no other
 >log4j.properties hanging around that the IDE or grep could find.
 >- We didn't extend the log4j code by writing Appenders or other classes.
 >- We are only using the basic Logger methods (.error() .warn(),
 >.isDebugEnabled(), etc)
 >- This is a multithreaded application running a home-made web-server.
 >
 >Clarification on the lines logged:
 >
 >... Some unrelated logging here that is not log4j-related here... the last
 >log4j-related loged info is hours before.
 >log4j: Hierarchy threshold set to [OFF].
 >log4j: Could not find root logger information. Is this OK?
 >log4j: Finished configuring.
 >... no more logging here
 >
 >Thanks,
 >
 >Cristian Jansenson
 >
 >-Original Message-
 >From: Cristian Jansenson [mailto:[EMAIL PROTECTED]
 >Sent: Monday, January 15, 2007 10:12 AM
 >To: log4j-user@logging.apache.org
 >Subject: Logging stops after hours working
 >
 >I am running an application that uses log4j version 1.2.9.  The
application
 >is running on Java 1.5.0.9 for Linux 64-bit version.  After minutes or
hours
 >of running and logging, log4j stops logging.  The console shows the
 >following message, which partially explains the reason:
 >
 >
 >
 >log4j: Hierarchy threshold set to [OFF].
 >
 >log4j: Could not find root logger information. Is this OK?
 >
 >log4j: Finished configuring.
 >
 >
 >
 >But why does this happen?  Since this information is printed from the
 >PropertyConfigurator, It looks as if log4j were re-configuring, even
though
 >I am NOT using the configureAndWatch method, and the log4j.properties file
 >was neither touched nor changed.
 >
 >
 >
 >My log4j.properties:
 >
 >
 >
 ># enable log4j debugging, and set threshold=ALL (see bug 10598)
 >
 >log4j.threshold=ALL
 >
 >log4j.debug=true
 >
 >
 >
 ># Set root logger level to DEBUG and its only appender to A1.
 >
 >log4j.rootLogger=ERROR, A1
 >
 >log4j.logger.http=WARN, HTTP
 >
 >
 >
 ># see bug 10603:  http should not inherit appenders, etc, from root.
 >
 >log4j.additivity.http=false
 >
 >
 >
 >log4j.appender.A1=org.apache.log4j.DailyRollingFileAppender
 >
 >log4j.appender.A1.File=logs/error-${port}.log
 >
 >log4j.appender.A1.DatePattern='.'-MM-dd
 >
 >
 >
 ># A1 uses PatternLayout.
 >
 >log4j.appender.A1.layout=org.apache.log4j.PatternLayout
 >
 >log4j.appender.A1.layout.ConversionPattern=%d{DATE} %x [%t] %-5p %c %x -
 >%m%n
 >
 >
 >
 >
 >
 ># HTTP Log config
 >
 >
 >
 >
 >
 >log4j.appender.HTTP=org.apache.log4j.DailyRollingFileAppender
 >
 >log4j.appender.HTTP.File=logs/http-${port}.log
 >
 >log4j.appender.HTTP.DatePattern='.'-MM-dd
 >
 >
 >
 ># A1 uses PatternLayout.
 >
 >log4j.appender.HTTP.layout=org.apache.log4j.PatternLayout
 >
 >
 >
 >log4j.appender.HTTP.layout.ConversionPattern=%m%n
 >
 >
 >
 >
 >
 >I hope you can help me on this issue,
 >
 >
 >
 >Cristian Jansenson



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


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.410 / Virus Database: 268.16.13/632 - Release Date: 1/16/2007
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.410 / Virus Database: 268.16.14/636 - Release Date: 1/18/2007
 


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