log4j 1.3 alpha 8 release now available
The log4j team is happy to announce the availability of log4j version 1.3alpha8. It can be downloaded from: http://logging.apache.org/site/binindex.cgi This version contains many changes to bring it back to better compatibility with log4j version 1.2.X, and more changes are planned for the upcoming alpha9 release as well. Users are encouraged to test this version with custom code that they have previously written for log4j version 1.2.X and to report any issues to the log4j dev email list. Please use your own judgement with this release, as it is an alpha release. We would suggest you use it for evaluation purposes only since more changes are planned. Curt Arnold, one of the committers leading the compatibility charge, is maintaining a compatibility report at: http://people.apache.org/~carnold/compatibility.html And a quick discussion of remaining issues can be found in the mail archive at: http://marc.theaimsgroup.com/?t=11381292391r=1w=2 Compatibility is a major goal for the current work on version 1.3. Full compatibility may not be achievable with the addition of new features or critical bug fixes, but it should be much better than it has been with previous releases of version 1.3. Remaining issues will be documented so affected users can deal with the differences. Once the major compatibility issues have been addressed, focus for the 1.3 release will shift to api/code review and solidifying the code for beta and release. The current plan calls for a release in mid 2006 timeframe. Thank you for your continued support! - The log4j team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
log4j 1.3 status update
Work continues on the next major version of log4j, 1.3. Going forward there will be monthly builds of 1.3, taking place on the last Wednesday of the month. More builds may be done as needed. The current focus of work for 1.3 is to restore most compatibility with version 1.2.X. These changes are under discussion on the log4j-dev email list, and we invite you to follow and participate if you want. There will likely be some changes that may affect drop in compatibility, especially if the changes are needed to support important new features we are adding. We will doing a better job of documenting these changes and getting feedback from all of you as to how much of an effect it will have. A goal is to make it easier to transition to version 1.3 than it is in the current alpha 7 version. thanks, -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between LogFactory.getLog Logger.getLogger ?
It depends on which package you want to use in your code. If you only want to reference loggers via commons-logging, use the commons logging one. If you want to reference loggers via log4j, use the log4j one. Even though commons-logging can use log4j under the covers, it does not directly expose the log4j logger class and its methods (though they are very, very similar). hth, -Mark On 12/22/05, DeMZed [EMAIL PROTECTED] wrote: Hi ! One is from org.apache.commons.logging and the other from org.apache.log4j. It seems that those two clases does the same work, so, which one choose ? Thanks :-) - 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]
Re: Difference between LogFactory.getLog Logger.getLogger ?
commons-logging is not part of the Logging Services or log4j project, it is part of the Jakarta project. Plus commons-logging can be used to wrap around other logging frameworks, like the JDK logging api (which makes it more usable in my opinion). If you think your project might need to swap out the logging framework at some point, then commons-logging might be for you. You can still get the power of log4j underneath it in the configuration of appenders, etc. There can be some issues with commons-logging though in the way it looks for the underlying framework, etc. The links that Curt sent in his email are pretty clear about it. hth, -Mark - Original Message - From: DeMZed [EMAIL PROTECTED] To: Log4J Users List log4j-user@logging.apache.org Sent: Thursday, December 22, 2005 11:06 AM Subject: Re: Difference between LogFactory.getLog Logger.getLogger ? Thanks :) If the use of the first in one class and the second in another class would not produce any diffrence, why isn't there only one use ? 2005/12/22, Mark Womack [EMAIL PROTECTED]: It depends on which package you want to use in your code. If you only want to reference loggers via commons-logging, use the commons logging one. If you want to reference loggers via log4j, use the log4j one. Even though commons-logging can use log4j under the covers, it does not directly expose the log4j logger class and its methods (though they are very, very similar). hth, -Mark On 12/22/05, DeMZed [EMAIL PROTECTED] wrote: Hi ! One is from org.apache.commons.logging and the other from org.apache.log4j. It seems that those two clases does the same work, so, which one choose ? Thanks :-) - 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]
Re: log4j documentation help?
Something like this is a good start, and I think we have pieces of it. But something a little more in-depth about the overall structure, flow, and points of configuration would be useful too. On 12/20/05, Ron Grabowski [EMAIL PROTECTED] wrote: Are you looking for something like this: http://logging.apache.org/log4net/release/manual/configuration.html http://logging.apache.org/log4net/release/config-examples.html Examples showing how to use each of the built-in appenders is helpful. - Original Message From: Mark Womack [EMAIL PROTECTED] To: Log4J Users List log4j-user@logging.apache.org Sent: Tuesday, December 20, 2005 6:15:47 PM Subject: Re: log4j documentation help? Wiki is good for learnings, and we can certainly do that, but we are looking to provide something more concrete/permanent than just wiki pages. We have started looking at tools like Maven2 which can provide a lot information about the project, but as I said, we want to start creating users manual type information. Starting with the overall usage and the top 10 asked questions would probably be a good start I imagine. -Mark On 12/20/05, James Stauffer [EMAIL PROTECTED] wrote: How about putting it in a wiki? Most of my helpful additions for documentation would just come as learn/use the code so that would be the easiest way to add helpful tidbits. On 12/20/05, Mark Womack [EMAIL PROTECTED] wrote: One of the tasks for the log4j 1.3 release (or even before that) is to create a better documentation set for log4j. This would be both the documentation that ships at part of the release and what is available from the web. I am speaking for myself, but I think most of the committers agree, that the current documentation on the web needs to be greatly updated and provide more information. I know that some of you out there have posted similar sentiments in the past. As I said, we are looking to updated it for at least the 1.3 release. So, we are looking for volunteers that want to do something about it. Maybe you want to write some clearer documentation, provide better examples, or know an out-of-work tech writer that would like to use it as a reference :-). The code API's will be handled by the generated javadoc's. What we are talking about here is more of a user's manual. We (the committers) are going to do a better job of it, but it just seems like documentation for the user community might be better served by getting that community directly involved. We want you involved. Any takers? Comments, suggestions? -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Stauffer 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] - 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]
log4j documentation help?
One of the tasks for the log4j 1.3 release (or even before that) is to create a better documentation set for log4j. This would be both the documentation that ships at part of the release and what is available from the web. I am speaking for myself, but I think most of the committers agree, that the current documentation on the web needs to be greatly updated and provide more information. I know that some of you out there have posted similar sentiments in the past. As I said, we are looking to updated it for at least the 1.3 release. So, we are looking for volunteers that want to do something about it. Maybe you want to write some clearer documentation, provide better examples, or know an out-of-work tech writer that would like to use it as a reference :-). The code API's will be handled by the generated javadoc's. What we are talking about here is more of a user's manual. We (the committers) are going to do a better job of it, but it just seems like documentation for the user community might be better served by getting that community directly involved. We want you involved. Any takers? Comments, suggestions? -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j documentation help?
Wiki is good for learnings, and we can certainly do that, but we are looking to provide something more concrete/permanent than just wiki pages. We have started looking at tools like Maven2 which can provide a lot information about the project, but as I said, we want to start creating users manual type information. Starting with the overall usage and the top 10 asked questions would probably be a good start I imagine. -Mark On 12/20/05, James Stauffer [EMAIL PROTECTED] wrote: How about putting it in a wiki? Most of my helpful additions for documentation would just come as learn/use the code so that would be the easiest way to add helpful tidbits. On 12/20/05, Mark Womack [EMAIL PROTECTED] wrote: One of the tasks for the log4j 1.3 release (or even before that) is to create a better documentation set for log4j. This would be both the documentation that ships at part of the release and what is available from the web. I am speaking for myself, but I think most of the committers agree, that the current documentation on the web needs to be greatly updated and provide more information. I know that some of you out there have posted similar sentiments in the past. As I said, we are looking to updated it for at least the 1.3 release. So, we are looking for volunteers that want to do something about it. Maybe you want to write some clearer documentation, provide better examples, or know an out-of-work tech writer that would like to use it as a reference :-). The code API's will be handled by the generated javadoc's. What we are talking about here is more of a user's manual. We (the committers) are going to do a better job of it, but it just seems like documentation for the user community might be better served by getting that community directly involved. We want you involved. Any takers? Comments, suggestions? -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Stauffer 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] log4j 1.2.13 release
The Logging Service project and log4j project are happy to announce the release of log4j 1.2.13. Version 1.2.13 contains several bug fixes related to the TRACE level introduced in version 1.2.12 and a fix in the ConsoleAppender for a bug that affected logging in JBoss. Please see the HISTORY.txt for more details. Enjoy! -The log4j project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j performance issues
Do you have any actual timing or profiling information that would lead you to suspect that log4j is causing the problem, or just anecdotal experience? There is nothing I can think of that changed so much in any of the recent log4j releases to account for the level of degradation you are describing and have not seen it myself. If you switch back to version 1.2.9, does your problem go away? -Mark On 11/3/05, Michael A Chase [EMAIL PROTECTED] wrote: In the most recent update to our system, I installed log4j 1.2.11. After the update someone at our hosting facility finally noticed that the application was taking a very long time to paint some screens. The application was frequently painfully slow to begin with, but someone latched on to log4j as something that had changed recently. In production, the application is calling Logger.getLogger() once for most class instantiations (5-10 per screen) and logger.warn() once per screen. There is only one appender which uses DailyRollingFileAppender. Has anyone seen log4j cause a noticeable performance degradation when writing one log entry per screen displayed? -- Mac :}) Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of log4j 1.3 and MDC bug
The 1.3beta7 build has been approved for release, I just have to move it to the right location. Hopefully the history file will have what you are looking for, but I don't know if that is guaranteed. I don't beleive this bug has been addressed in the new build. I plan to move the build to the download locations tonight. -Mark On 11/2/05, Hein Meling [EMAIL PROTECTED] wrote: Dear log4j developers, I'm wondering if this bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=32752 has been solved in the svn repository; it has not changed its status since it was reported almost a year ago. Also, I've been seeing sporadic mentions of a new alpha release. Is there something concrete that you guys can say about when we can see a new alpha (or beta) release. I would really appreciate it if you could also provide a list of changes that will appear in the coming release; that is since 1.3beta6. Thank you, Hein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of log4j 1.3 and MDC bug
Sorry, that would 1.3 *alpha* 7, not beta. -Mark On 11/2/05, Mark Womack [EMAIL PROTECTED] wrote: The 1.3beta7 build has been approved for release, I just have to move it to the right location. Hopefully the history file will have what you are looking for, but I don't know if that is guaranteed. I don't beleive this bug has been addressed in the new build. I plan to move the build to the download locations tonight. -Mark On 11/2/05, Hein Meling [EMAIL PROTECTED] wrote: Dear log4j developers, I'm wondering if this bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=32752http://www.google.com/url?sa=Dq=http%3A%2F%2Fissues.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D32752 has been solved in the svn repository; it has not changed its status since it was reported almost a year ago. Also, I've been seeing sporadic mentions of a new alpha release. Is there something concrete that you guys can say about when we can see a new alpha (or beta) release. I would really appreciate it if you could also provide a list of changes that will appear in the coming release; that is since 1.3beta6. Thank you, Hein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] log4j-1.3alpha7 available
The log4j project is proud to announce that the next alpha release of version 1.3, 1.3alpha7, is now available for download. http://logging.apache.org/site/binindex.cgi (mirror sites may need some time to pick up the new distribution) Enjoy! -The log4j project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FileWatchDog
Thanks for the suggestion. But what happens when the filewatchdog detects a subsequent change in the configuration file? Is the file wiped again? Would it be better to enable the append settings on the FileAppender? There are little issues like this that need to be looked at for the watchdogs. In some cases, you might want the watchdog to do the initial configuration. -Mark On 10/18/05, William Ferguson [EMAIL PROTECTED] wrote: Hi If you're planning changes for FileWatchDog in the coming 1.3 release, I'd like to request that it determines the lastModified time of the File in the FileWatchDog constructor prior to calling #checkAndConfigure. Otherwise any existing log file is erased when the FIleWatchDog executes its first check and in an enterprise application you're not always in control of when that might happen. We've had to introduce our own DOMConfigurator, XMLWatchDog and FileWatchDog to stop our log file being wiped. William
Re: heartbeat to trigger log rotation
I would need to check, but I think this will be fixed in v1.3. -Mark On 10/17/05, Philip Denno [EMAIL PROTECTED] wrote: You could implement a timer in your code to write some data at a specified period (say midnight). I don't think this can be done from log4j configuration. Cheers, Philip. -Original Message- From: Fong Vang [mailto:[EMAIL PROTECTED] Sent: October 17, 2005 1:07 PM To: log4j-user@logging.apache.org Subject: heartbeat to trigger log rotation Even though some of our log files use the DailyRollingFileAppender (set to rotate log daily), several of our logs are not being rotated because they don't get any activity. What's the easiest way to configure log4j to rotate a log file regardless of activities or not? What's the easiest way to add a heartbeat if this functionality doesn't exist? TIA! - 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]
Re: PropertyConfigurator.configureAndWatch
Yes, configureAndWatch has been removed in favor of the Watchdog mechanism. There should be a FileWatchdog as part of the 1.3 package. It has been generally tested, but probably needs more. Especially around configuring it from config files and what happens when the file actually updates. That whole mechanism is on my plate for the 1.3 review and push to beta. One thing of note with the Watchdogs is that they are no longer tied to a specific configurator class. The watchdog can support any Configurator and does not require any support or changes from the configurator (though we had to add one new method to the Configurator interface). -Mark On 10/5/05, Jacob Kjome [EMAIL PROTECTED] wrote: Quoting Boddapati, Vijaya [EMAIL PROTECTED]: Hi, I have downloaded the latest version of log4j(1.3 alpha). But I could not locate the method configureAndWatch in PropertyConfigurator class. Please point me to the exact class. configureAndWatch() has been removed in Log4j-1.3. It is also not recommended to use this in Log4j-1.2 either if you are running in a J2EE environment. I believe Mark Womack was working on File Watchdogs and such, but I can't quite recall where he was with all that? Mark, can you comment? Jake Thanks Vijaya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyConfigurator.configureAndWatch
You are right. We should not have removed the api, and reviewing the api changes we have made is a task for the 1.3 beta. We should look at what is different and if we want to live with it, put it back, deprecated it, etc. I believe that, yes, configureAndWatch could be implemented with the FileWatchdog. It will probably have slightly different behavior (like not allowing multiple watchers from multiple calls to the method), but I think it would be better behavior. Or we could leave it. The big deal breaker was that there was not way to shutdown the watcher in the web server environment. This would be fixed with the new plugin stuff. -Mark - Original Message - From: Scott Deboy [EMAIL PROTECTED] To: Log4J Users List log4j-user@logging.apache.org Cc: Log4J Developers List log4j-dev@logging.apache.org Sent: Wednesday, October 05, 2005 8:36 AM Subject: RE: PropertyConfigurator.configureAndWatch We can't remove the api without deprecating it 1st, so log4j 1.3 should support the configureandwatch methods. Is the plan to have domconfigurator.configureandwatch (and propertyconfigurator?) leverage a watchdog? I thought we had discussed this before but don't see it in the mailing list archive. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4J Eclipse
It would be cool if we could plug Chainsaw into Eclipse. Paul, Scott, how hard do you think that would be? -Mark On 10/4/05, Alan Gutierrez [EMAIL PROTECTED] wrote: * Robert Hedin [EMAIL PROTECTED] [2005-10-04 11:03]: Checkout the Ganymede Plugin for Eclipse: http://sourceforge.net/projects/ganymede/ Basically, you setup your appenders to use a SocketAppender and this listens for logging messages and displays them, color coded, in a table. Also allows you to filter the messages, etc. Perfect. -- Alan Gutierrez - [EMAIL PROTECTED] - http://engrm.com/blogometer/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot turn off logging when using Junit - SOLVED
The libs are not included in the cvs due to various licensing issues. At
least at the time that was the issue I remember. We should revisit it as
part of the 1.3 push. I'm sure we can include the Apache jars and I would
like the build process to be as self-contained as possible. You could always
override with a version of the jars you preferred, but the repository would
contain the versions the official builds are built with.
But glad to hear you were able to work through the build locally.
-Mark
On 9/29/05, Rakesh Patel [EMAIL PROTECTED] wrote:
Hi,
Ok I built from source using the latest in cvs. It wasn't as hard as I
thought it would be (not sure why all 3rd party libs are not included
though in cvs?).
Turning the logging to OFF does what I need now!
Thanks for the help,
Rakesh
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: 29 September 2005 15:12
To: Log4J Users List
Subject: RE: Cannot turn off logging when using JUnit
Quoting Rakesh Patel [EMAIL PROTECTED]:
I am indeed using the 1.3 alpha version.
However, adding this line makes no difference:
log4j.logger.org.apache.log4j=WARN
Jake, your last paragraph contradicts itself. You say the internal
code cannot be overriden and then you say it can?
Sorry if I wasn't clear. When I said Note that, besides this, I meant
to exclude the rest of the comments from the previously described
hardcoded behavior that is in the current alpha, but removed from the
latest source.
So, there is no contradiction. They were two completely separate trains
of thought of two entirely different logging issues.
Any idea when the next release will fix this (no time to build from
source)?
I believe that some of the developers are working on getting a new
release out as we speak!
Jake
Thanks
Rakesh
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: 28 September 2005 23:14
To: Log4J Users List; Mark Womack
Subject: Re: Cannot turn off logging when using JUnit
Quoting Mark Womack [EMAIL PROTECTED]:
Can we assume that you are using the 1.3 alpha version? You will
want to add configuration to set org.apache.log4j to WARN/ERROR or
OFF.
I think at some point, the auto-logging of logger creation internal to
Log4j-1.3 in CVS was removed. The current release alpha still has it
turned on no matter what.
I suggest either waiting for the next alpha release or building
yourself from source. Note that, besides this, you control log4j
internal logging using normal log4j configuration, just like any other
logger. So, if you want to turn off log4j logging, then make sure to
set the level pretty high for the org.apache.log4j logger.
Jake
hth,
-Mark
On 9/28/05, Rakesh Patel [EMAIL PROTECTED] wrote:
Hi,
I have a test set up that logs and also the class under test logs
too.
I want to turn of logging at times but am finding that the console
ALWAYS logs INFO messages of the loggers being created (my user
defined log entries are not displayed).
I've tried various settings in the property file but I just cannot
stop these entries going to the console.
Here's my property file:
log4j.rootLogger=OFF, stdout, R
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
# Print the date in ISO 8601 format
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c -
%m%n
#log4j.appender.R=org.apache.log4j.FileAppender
log4j.appender.R.File=app.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d %-5p %c - %m%n
# Vary level for packages log4j.logger.org.springframework=ERROR
And here's the bit of my initialisation code in my Junit setUp:
protected void setUp() throws Exception {
PropertyConfigurator.configure(c:/Projects/FETServer/conf/log4j.p
ro
pert
ies);
// initialise datasource
_logger.info(One-time setUp());
_logger.info(intializing connection...);
dataSource = new SingleConnectionDataSource();
dataSource.setDriverClassName(
oracle.jdbc.driver.OracleDriver);
dataSource.setUrl(
jdbc:oracle:thin:@132.25.50.69:1521:ORCL01);
dataSource.setUsername(scott);
dataSource.setPassword(tiger);
dao = new SampleDao(dataSource);
}
And here's whats going to the console:
*** configurationOptionStr=null
** End of LogManager static initializer
log4j:INFO Creating new logger
[com.amex.ifst.fet.dao.TestSampleDao]
in repository [default]. log4j:INFO Creating new logger
[org.apache.log4j] in repository [default]. log4j:INFO Creating
new logger
[org.apache.log4j.PropertyConfigurator]
in repository [default].
log4j:INFO Returning existing logger
Re: Cannot turn off logging when using JUnit
Can we assume that you are using the 1.3 alpha version? You will want to add
configuration to set org.apache.log4j to WARN/ERROR or OFF.
hth,
-Mark
On 9/28/05, Rakesh Patel [EMAIL PROTECTED] wrote:
Hi,
I have a test set up that logs and also the class under test logs too.
I want to turn of logging at times but am finding that the console
ALWAYS logs INFO messages of the loggers being created (my user defined
log entries are not displayed).
I've tried various settings in the property file but I just cannot stop
these entries going to the console.
Here's my property file:
log4j.rootLogger=OFF, stdout, R
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
# Print the date in ISO 8601 format
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
#log4j.appender.R=org.apache.log4j.FileAppender
log4j.appender.R.File=app.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d %-5p %c - %m%n
# Vary level for packages
log4j.logger.org.springframework=ERROR
And here's the bit of my initialisation code in my Junit setUp:
protected void setUp() throws Exception {
PropertyConfigurator.configure(c:/Projects/FETServer/conf/log4j.propert
ies);
// initialise datasource
_logger.info(One-time setUp());
_logger.info(intializing connection...);
dataSource = new SingleConnectionDataSource();
dataSource.setDriverClassName(
oracle.jdbc.driver.OracleDriver);
dataSource.setUrl(
jdbc:oracle:thin:@132.25.50.69:1521:ORCL01);
dataSource.setUsername(scott);
dataSource.setPassword(tiger);
dao = new SampleDao(dataSource);
}
And here's whats going to the console:
*** configurationOptionStr=null
** End of LogManager static initializer
log4j:INFO Creating new logger [com.amex.ifst.fet.dao.TestSampleDao] in
repository [default].
log4j:INFO Creating new logger [org.apache.log4j] in repository
[default].
log4j:INFO Creating new logger [org.apache.log4j.PropertyConfigurator]
in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Creating new logger [org.apache.log4j.config.PropertySetter]
in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Creating new logger
[org.apache.log4j.helpers.OptionConverter] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Creating new logger [org.springframework] in repository
[default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger
[org.apache.log4j.PropertyConfigurator] in repository [default].
log4j:INFO Returning existing logger [org.apache.log4j] in repository
[default].
log4j:INFO Creating new logger
[org.springframework.jdbc.datasource.SingleConnectionDataSource] in
repository [default].
log4j:INFO Creating new logger [com.amex.ifst.fet.dao.SampleDao] in
repository [default].
log4j:INFO Creating new logger
[org.springframework.jdbc.core.JdbcTemplate] in repository [default].
log4j:INFO Creating new logger
[org.springframework.jdbc.datasource.DataSourceUtils] in repository
[default].
log4j:INFO Creating new logger
[org.springframework.transaction.support.TransactionSynchronizationManag
er] in repository [default].
log4j:INFO Creating new logger
[org.springframework.jdbc.support.JdbcUtils] in repository [default].
log4j:INFO Creating new logger
[org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator] in
repository [default].
log4j:INFO Creating new logger
[org.springframework.jdbc.support.SQLStateSQLExceptionTranslator] in
repository [default].
log4j:INFO Creating new logger
[org.springframework.jdbc.support.SQLErrorCodesFactory] in repository
[default].
log4j:INFO Creating new logger
[org.springframework.beans.factory.support.DefaultListableBeanFactory]
in repository [default].
log4j:INFO Creating new logger
Re: log4j doubt
1) If you are logging to a file, then the machine where the logging is being performed will need access to the volume. Please be aware that a file cannot be shared across multiple log4j instances, only one instance can have the file open at one time in the current implementation. If you do not want to have the volume mounted on the machine, then you should look at the other appenders that allow remote appending like SocketAppender or JMSAppender. 2) Appenders can have filters defined for them that will conditionally allow logging events through to the appender. These filters have become fairly rich and configurable in the upcoming 1.3 version but there is a very usable set in the 1.2.X release and it is very easy to implement your own if you need more. hth, -Mark - Original Message - From: bussa srikanth [EMAIL PROTECTED] To: log4j-user@logging.apache.org Sent: Saturday, September 24, 2005 4:07 PM Subject: log4j doubt Hi Apache logger has support for logging into files through file appender. But, if my file is existing on a different location on the intranet, how should i specify that network location in the log4j.properties? Also, please point to the issues that are inherently present with this sort of remote logging. 2. Supposing that we define a new appender for logging onto a n/w file, how to conditionally instruct logger to log to that appender when a special case is satisfied? what i know is that when logging has to be done, apache logger does so dutifully to all the appeneders defined in the log4j.properties file thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Turn Off log4j Logs
I think you will need to add something to your configuration to set ' org.apache.log4j' to WARN/ERROR. This is something we need to look into in the drive to beta. hth, -Mark On 9/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello! How can I turn off the logj4 logs ins Log4J 1.3 alpha 6? They appear like this: log4j:INFO Returning existing logger [org.apache.log4j.joran.spi.Interpreter] in repository [default]. log4j:INFO Returning existing logger [org.apache.log4j.joran.spi.Interpreter] in repository [default]. log4j:INFO Returning existing logger [org.apache.log4j.joran.spi.Interpreter] in repository [default]. log4j:INFO Returning existing logger [org.apache.log4j.joran.spi.Interpreter] in repository [default]. log4j:INFO Returning existing logger [org.apache.log4j.joran.spi.Interpreter] in repository [default]. Thanks, Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Officla log4j 1.2.12 Release
The log4j team is proud to announce the official release of log4j 1.2.12! This new version contains a number of bug fixes, the addition of the much requested TRACE level, and is compile and runtime compatible with the earlier JDK's 1.1 and 1.2 (this feature had been inadvertently broken in version 1.2.11). Other than the addition of the TRACE level, the api is identical to earlier versions of 1.2.X. You can download version 1.2.12 from: http://logging.apache.org/site/binindex.cgi The log4j team expects this to be the last release for the log4j 1.2.X series. Focus is now going to be applied to completing the long awaited version 1.3 which will have a number of additions and improvements (early alpha versions are also available at the above link). Thank you for your continued support! -The log4j team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Officla log4j 1.2.12 Release
Well, there is only so much you can fit into a dot release...:-) But we will certainly take the patch into consideration for the 1.3 release too. I don't know how likely it is at this point (we need to review the tasks, etc), but we were hoping to have 1.3 released before the end of this year. -Mark -Original Message- From: Nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: Thursday, September 08, 2005 8:40 AM To: Log4J Users List Subject: Re: Officla log4j 1.2.12 Release I'm so sory my patch is not include in this version ;-( (http://issues.apache.org/bugzilla/show_bug.cgi?id=35996) I'll have to wait for 1.2.13... Nico. Mark Womack a écrit : The log4j team is proud to announce the official release of log4j 1.2.12! This new version contains a number of bug fixes, the addition of the much requested TRACE level, and is compile and runtime compatible with the earlier JDK's 1.1 and 1.2 (this feature had been inadvertently broken in version 1.2.11). Other than the addition of the TRACE level, the api is identical to earlier versions of 1.2.X. You can download version 1.2.12 from: http://logging.apache.org/site/binindex.cgi The log4j team expects this to be the last release for the log4j 1.2.X series. Focus is now going to be applied to completing the long awaited version 1.3 which will have a number of additions and improvements (early alpha versions are also available at the above link). Thank you for your continued support! -The log4j team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - 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]
SVN migration
I know all the committers have probably been following the discussion on logging general, but just so everyone knows...we are planning to migrate the logging services cvs repositories to svn (subversion) this weekend, 9/10. Converting to svn is an apache-wide initiative and besides it being a different repository with its own set of clients, etc, there won't be much difference to anyone besides those that access the source via cvs today. As part of the migration, the committers will be verifying that the existing code and processes are properly migrated and functional. We'll post more specific information when we have it. Fyi, -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4J Control Panel
There is a simple one in the log4j-sandbox. It could use some attention from a caring soul... :-) -Mark -Original Message- From: James Stauffer [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 8:46 AM To: Log4J Users List Subject: Re: Log4J Control Panel I think there is one on the log4j site also (maybe in an examples directory). On 9/2/05, Durfee, Bernard [EMAIL PROTECTED] wrote: Okay, I found one... http://www.codeczar.com/products/logweb/index.html Bernie -Original Message- From: James Stauffer [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 10:45 AM To: Log4J Users List Subject: Re: Log4J Control Panel I think there is a servlet to do that. Try searching for a log4j servlet. On 9/2/05, Durfee, Bernard [EMAIL PROTECTED] wrote: Is there an web application that will allow me to configure Log4J during runtime without bouncing the application server? Thanks, Bernie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Stauffer 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Stauffer 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4j, websphere, rad, and log4j.xml location
You sure that is how you are configuring? PropertyConfigurator cannot process xml files. -Mark -Original Message- From: Schuweiler, Joel J. [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 2:02 PM To: log4j-user@logging.apache.org Subject: Log4j, websphere, rad, and log4j.xml location I am trying to configure log4j using PropertyConfigurator.configure(log4j.xml); I am however having an issue. I never receive a logging event. When I look at the websphere log, log4j says it is unable to find log4j.xml. I'm using RAD (IBM's Rappid Application Developer) to write the program that uses the log4j and I'm wondering exactly what I need to feed it for a path to this file. I can not use an absolute path because I will never know what that absolute path is since it will be running in websphere. Another issue I'm having is when I import an external jar and then upload my war to websphere it can't find any of the log4j stuff. I can include exact errors if this will help. thanks Joel Schuweiler Middleware [EMAIL PROTECTED] Tel: 8-7900 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Log4j, websphere, rad, and log4j.xml location
Well, unless you actually have properties in a file with .xml for the file type, you should be using DOMConfigurator. Is the file in property or xml format? -Mark -Original Message- From: Schuweiler, Joel J. [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 2:11 PM To: 'Log4J Users List' Subject: RE: Log4j, websphere, rad, and log4j.xml location Wow. Nice. I've used it before and it works. What should I be using with xml files? :P -Original Message- From: Mark Womack [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 4:10 PM To: 'Log4J Users List' Subject: RE: Log4j, websphere, rad, and log4j.xml location You sure that is how you are configuring? PropertyConfigurator cannot process xml files. -Mark -Original Message- From: Schuweiler, Joel J. [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 2:02 PM To: log4j-user@logging.apache.org Subject: Log4j, websphere, rad, and log4j.xml location I am trying to configure log4j using PropertyConfigurator.configure(log4j.xml); I am however having an issue. I never receive a logging event. When I look at the websphere log, log4j says it is unable to find log4j.xml. I'm using RAD (IBM's Rappid Application Developer) to write the program that uses the log4j and I'm wondering exactly what I need to feed it for a path to this file. I can not use an absolute path because I will never know what that absolute path is since it will be running in websphere. Another issue I'm having is when I import an external jar and then upload my war to websphere it can't find any of the log4j stuff. I can include exact errors if this will help. thanks Joel Schuweiler Middleware [EMAIL PROTECTED] Tel: 8-7900 - 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]
RE: Log4j, websphere, rad, and log4j.xml location
If you just use log4j, by default it looks for a file named log4j.xml or log4j.properties in the classpath. If it finds one of them, then it uses it to configure itself (with the proper configurator). There are schemes for initializing log4j in a web application if you have a different name for your file or want it to live in a different place. There are servlets and app context listeners that can be configured to locate the file and then use it to configure. -Mark -Original Message- From: Schuweiler, Joel J. [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 2:18 PM To: 'Log4J Users List' Subject: RE: Log4j, websphere, rad, and log4j.xml location I would think with the absolute path there would have to be some way to use the proper ../ combination to get yourself to the right directory? Or build off of the assumed root directory? Or am I missing something important? -Original Message- From: Jan Pernica [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 4:16 PM To: Log4J Users List Subject: Re: Log4j, websphere, rad, and log4j.xml location The absolute path Schuweiler, Joel J. wrote: For which of the issues? -Original Message- From: Jan Pernica [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 4:06 PM To: Log4J Users List Subject: Re: Log4j, websphere, rad, and log4j.xml location We use the same but you have to specify the JNDI name to load it correctly or do not provide file name but provide it as a resource stream Jan Schuweiler, Joel J. wrote: I am trying to configure log4j using PropertyConfigurator.configure(log4j.xml); I am however having an issue. I never receive a logging event. When I look at the websphere log, log4j says it is unable to find log4j.xml. I'm using RAD (IBM's Rappid Application Developer) to write the program that uses the log4j and I'm wondering exactly what I need to feed it for a path to this file. I can not use an absolute path because I will never know what that absolute path is since it will be running in websphere. Another issue I'm having is when I import an external jar and then upload my war to websphere it can't find any of the log4j stuff. I can include exact errors if this will help. thanks Joel Schuweiler Middleware [EMAIL PROTECTED] Tel: 8-7900 Příchozí zpráva neobsahuje viry. Zkontrolováno Antivirovým systémem AVG. Verze: 7.0.338 / Virová báze: 267.10.6/69 - datum vydání: 11.8.2005 - 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]
log4j 1.2.12rc1 release
The log4j team is working towards the official release of v1.2.12 which is primarily a maintenance release with fixes for some annoying bugs. To this end, the 1.2.12rc1 build has been created. This is not an official release, it is a release candidate, and should be treated that way. It is provided for review and sanity checking. As such, it is not available from the official distribution site. It can be found at: http://people.apache.org/~mwomack/log4j-1.2.12rc1/ You can find the list of changes in the docs/HISTORY.txt directory of the release. More release candidate versions are planned as there are still bugs open for the 1.2.12 release. Besides bug fixes, the rc1 release also contains the change to add the TRACE level to the available levels, a much requested feature. Our testing indicates that this does not appear to break anything related to earlier versions of log4j, but we would like your help in determining this, especially concerning serialization, an area we thought would have issues. If you have the time and resources, please substitute 1.2.12rc1 in a testing/staging environment and let us know if you find issues. Again, please be aware that 1.2.12rc1 is NOT an official release, so don't go and put it into your production environment. If you find any problems or issues, please let us know either on this email list of the log4j-dev email list. We appreciate any time and effort you can put into helping us test this new version. The timeline for releasing an official version of 1.1.12 is fairly soon. It will probably be within the next couple of weeks, depending on the feedback and/or issues. Thanks, The log4j team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: In Log4J 1.3alpha-6 DOMConfigurator.configureAndWatch() method has been removed
+1. I think this falls into the making sure 1.3 is as api compatible with 1.2 as we can make it category. Curt and Jake have done some good things around this, but we should all review the areas we are familiar with. In this particular case, we an probably even change the underlying functionality to use the new FileWatchdog so that it will not create a new thread every time it is called, and it will end the thread appropriately when the repository resets/shutsdown. But still deprecate it. -Mark -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 9:02 AM To: Log4J Users List; [EMAIL PROTECTED] Subject: RE: In Log4J 1.3alpha-6 DOMConfigurator.configureAndWatch() method has been removed This is an api used by external folks (including myself) and we should deprecate the method instead of removing it. If we need to put big warnings in the JavaDoc about usage and change the underlying implementation to use the new plugin framework, that's fine. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: In Log4J 1.3alpha-6 DOMConfigurator.configureAndWatch() method has been removed
Nicolas, Yes. Watchdogs will become more of a first order class/interface and will come in several implemented flavors: FileWatchdog, URLWatchdog, SocketWatchdog. Watchdogs are based on the new Plugin structure, and as such will be configurable from config files. Also, Watchdogs will support any Configurator, not just PropertyConfigurator or XMLConfigurator; no modification to the Configurator will be required for one of its sources to be watched. org.apache.log4j.watchdog.FileWatchdog is currently in the cvs, so you can try it out, but be aware that more testing and review is needed. That is one of my tasks for the 1.3 release. -Mark -Original Message- From: Nicolas Martignole [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 26, 2005 6:38 AM To: log4j-user@logging.apache.org Subject: In Log4J 1.3alpha-6 DOMConfigurator.configureAndWatch() method has been removed Hi I just downloaded log4j 1.3alpha-6 for testing. The method configureAndWatch(String s) from org.apache.log4j.xml.DOMConfigurator has been removed from the code (see DOMConfigurator v 1.68 under CVS) apparently due to thread issue. It seems that this was done after 1.3alpha-1. I'd like to know if there's an alternative for this method planned in 1.3 ? Thanks Nicolas Martignole See CVS tree here for DOMConfigurator http://cvs.apache.org/viewcvs.cgi/jakarta- log4j/src/java/org/apache/log4j/xml/DOMConfigurator.java?rev=1.73view=log - 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]
RE: log4j download broken links
What page did you access this bad link from? -Original Message- From: Allen Kardakaris [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 20, 2005 5:41 AM To: log4j-user@logging.apache.org Subject: log4j download broken links The link for the *logging-log4j-1.3alpha-6* [.tar.gz and .zip] on all mirrors seems to be corrupt. It reads *http://hostlogging/log4j/1.3alpha-6/logging-log4j-1.3alpha-6.ext *or *http://host/distlogging/log4j/1.3alpha-6/logging-log4j-1.3alpha- 6.ext* instead of *http://host/logging/log4j/1.3alpha-6/logging-log4j-1.3alpha-6.ext *or *http://host/dist/logging/log4j/1.3alpha-6/logging-log4j-1.3alpha- 6.ext* (no / between host / host/dist and logging). I can dowload the archive from the (manually edited) second link OK. -Allen - 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]
RE: Apache Commons Collection - CompositeConfiguration
Well, if CompositeConfiguration supports getting a Properties object to represent the configuration settings, then you could plug it into the PropertyConfigurator through doConfigure(Properties, LoggerRepository) pretty easily. Though there is no way to do automatic, default configuration (ie a single property or xml file). You'll have to write your on code to create the CompositeConfiguration and then pass it into PropertyConfigurator. related-but-not-exactly-helpful-to-your-current-context I think it is a weakness of the Configurator interface that it requires you to support/specify a file, etc. And then each configurator has to define source specific methods. It would be nice if it could use a wrapper interface where implementations could wrap a file, or a stream, or a CompositeConfiguration, etc. Haven't thought about it very hard, so not sure what it would look like, but something that says give me all the appender settings configured in this configuration, give me all the logger settings configured in this configuration, etc. Leave it up to the implementation to figure out the details. Then the common code would be responsible for actually configuring the environment using the data. Hm. /related-but-not-exactly-helpful-to-your-current-context -Mark -Original Message- From: Moran Ben-David [mailto:[EMAIL PROTECTED] Sent: Monday, July 18, 2005 3:48 PM To: log4j-user@logging.apache.org Subject: Apache Commons Collection - CompositeConfiguration Hi. I am looking to configure Log4J in my app to use a composite configuration (one based on multiple files). Has anyone done this before? (I searched the list and didn't find any mention of it.) Am I correct in wanting to extend through org.apache.log4j.config to do this? Does anyone have information on how to use the org.apache.log4j.config http://logging.apache.org/log4j/docs/api- unstable/org/apache/log4j/config/p ackage-frame.html package and extend with it? I'm going through the javadoc but was hoping that someone else was kind enough to document this process. Here's more info on what I'm trying to do in case anyone is kind enough to lend some eyes and braincells: I want the configuration that log4j will use to be derived from a series of files and not just from a single file. Propreties existing in two files, will be overriden by the higher priority file (i.e. the earlier one in the list or vice versa). I'm thinking that the best way to do this is to use the Apache Common Configuration framework's CompositeConfiguration: CompositeConfiguration config = new CompositeConfiguration(); config.addConfiguration(new SystemConfiguration()); config.addConfiguration(new PropertiesConfiguration(application.properties)); And then to get Log4J to pickup it's configuration from that config object. Now comes the task of plugging into log4j. Any answers to the questions above would be greatly appreciated. Thanks Moran Ben-David http://www.place-base.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reloading the config file
You are correct. It is only a file watcher, not a url watcher. v1.3 will have a much richer set of functionality that can watch a file, url, or a socket for updated configuration data and it will also support any Configurator. -Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 14, 2005 8:20 AM To: log4j-user@logging.apache.org Subject: Reloading the config file The log4j Configurator class has a method configureAndWatch(String configFilename, long delay) which can check that a config file has changed and, if so, reload it (delay being the reload interval). This is a very convenient method. However, it seems that this method can only be applied to local files, not to URLs, and that it won't reload a config file located on a remote server. Am I correct? --Fred Mora - 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]
Fw: ApacheCon US 2005: Call for Participaton
- Original Message - From: Rodent of Unusual Size [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 13, 2005 3:27 PM Subject: ApacheCon US 2005: Call for Participaton -BEGIN PGP SIGNED MESSAGE- In case you missed the news, ApacheCon US 2005 has been scheduled for 10-14 December 2005 in San Diego, California! See http://ApacheCon.Com/2005/US/ And the Call for Participation is open, so if you want to be a speaker, please submit your proposals now! Submit CF proposals at http://ApacheCon.com/html/cfp.html/e=MjAwNS9VUw The deadline is Tuesday, 9 August 2005. And because scheduling will begin immediately thereafter, NO LATE SUBMISSIONS CAN BE ACCEPTED! Hope to see you there! - -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBQtWVXprNPMCpn3XdAQGwRwQA1gqnEQrCS1DAttRGRaIoLLYPVbY7j+9f zvo9ipuWosazsaSC/7kpO+WnshcDLvVTDF83ZZvztqXmoVYCHQvixJ0XDKCmMT3O h3U2768x4qkAtgrDWPS31D1oT1NJS4pd+SywksdIwDB4JMgHLhC8liUz8bQY5AjB Ifxz4wwViuM= =58HL -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getting the log4net appenders at runtime
Tom, I think you want the log4net-dev email list.
-Mark
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Tom Regan
Sent: Tuesday, July 12, 2005 9:37 AM
To: log4j-user@logging.apache.org
Subject: getting the log4net appenders at runtime
My root appender writes to a text file. I need to get the path to the
text
file at runtime (the FileAppender.File property). Is there any way to do
that?
For example, this pulls back an empty collection of file appenders. How
do I
get the full one? I'm doing this after calling
DomConfigurator.Configure():
log4net.Repository.Hierarchy.Hierarchy h =
(log4net.Repository.Hierarchy.Hierarchy)log4net.LogManager.GetLoggerReposi
tory
();
foreach(log4net.Appender.FileAppender fa in h.Root.Appenders)
{
string s = a.File;
}
The log4net.helpers.AppenderAttachedImpl object has an Appenders
collection.
But how do I instantiate an AppenderAttachedImpl object so that it pulls
back
the Appenders collection for the current log4net configuration?
For example, if I simply instantiate it like so:
log4net.helpers.AppenderAttachedImpl = new
log4net.helpers.AppenderAttachedImpl
()
I also get back an empty collection of appenders.
-
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]
RE: getting the log4net appenders at runtime
Or the log4net-user email list, sorry.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Tom Regan
Sent: Tuesday, July 12, 2005 9:37 AM
To: log4j-user@logging.apache.org
Subject: getting the log4net appenders at runtime
My root appender writes to a text file. I need to get the path to the
text
file at runtime (the FileAppender.File property). Is there any way to do
that?
For example, this pulls back an empty collection of file appenders. How
do I
get the full one? I'm doing this after calling
DomConfigurator.Configure():
log4net.Repository.Hierarchy.Hierarchy h =
(log4net.Repository.Hierarchy.Hierarchy)log4net.LogManager.GetLoggerReposi
tory
();
foreach(log4net.Appender.FileAppender fa in h.Root.Appenders)
{
string s = a.File;
}
The log4net.helpers.AppenderAttachedImpl object has an Appenders
collection.
But how do I instantiate an AppenderAttachedImpl object so that it pulls
back
the Appenders collection for the current log4net configuration?
For example, if I simply instantiate it like so:
log4net.helpers.AppenderAttachedImpl = new
log4net.helpers.AppenderAttachedImpl
()
I also get back an empty collection of appenders.
-
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]
RE: How to use Log4J in Multiple classes? App Design?
The assumption here is that you have named your classes and packages in some
coherent, logical, useful fashion, as in:
com.mycompany.package1.classA
com.mycompany.package1.classB
com.mycompany.package2.classC
com.mycompany.package2.classD
If you do this, then this gives you maximum flexibility in the configuration
file to control log output by specific class or an entire (related)
package...
Hth,
-Mark
-Original Message-
From: Paul Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 12, 2005 5:03 PM
To: Log4J Users List
Subject: Re: How to use Log4J in Multiple classes? App Design?
I would really suggest you follow the standard pattern and have one
Logger per class ala:
public class MyClass {
private static final Logger LOG = Logger.getLogger(MyClass.class);
Let each class log it's own stuff.
Paul Smith
On 13/07/2005, at 9:57 AM, John Hurt wrote:
Hi,
My application is split up into multiple classes. If I had
processing in
each class that I wanted to log, what's the best way to make a
reference to
the Logger available, so that for instance they all write to the
same log
file?
Do I create an instance of the Logger class at the beginning of the
program
flow, then pass that class to all the methods/classes that plan to do
logging?
Do I make a wrapper singleton class that has a Logger in it and all
code
refers to the wrapper class?
Do I use a base class (or interface or abstract class) that includes a
reference to a Logger class?
Anyone has generic examples where Logger is used in more than 1
class, how
to use it gracefully? Thanks.
-
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]
RE: Clarification
This is bug 9150 in the log4j bug db, and will be fixed in the upcoming 1.2.12 version. I got the fix together over the weekend, but still working on a unit test before checking it into cvs. -Mark -Original Message- From: James Stauffer [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 06, 2005 10:07 AM To: Log4J Users List; [EMAIL PROTECTED] Subject: Re: Clarification log4j will create the file but not the directories. (I ended up creating my own appender that creates the directories also). On 7/6/05, Balaji Saranathan [EMAIL PROTECTED] wrote: Can you tell me if log4j creates the log file (if they are not present) when using the FileAppenders or is it the responsibility of the developers to create the log files? -- James Stauffer 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.2.12 Bug Fix Candidates
Since it has been brought up in relation to bug #9150, I would like to open this up to the log4j users. Please review bugs in the log4j bug database, and if there is a bug that you would like considered for fixing in the 1.2.12 release, then enter the phrase 1.2.12 candidate in the bug comments. Other notes and comments as to why you feel it is important will also be useful. If you have a bug that is not in the database, please enter it. The log4j committers are the final arbiters as to which bug fixes will be included, but obviously we want feedback from all of you. Bug fixes with good explanations, patches, and test cases have the best chance of acceptance. Please be aware that 1.2.12 is just a update release, so we won't be going crazy with bug fixes. Just major and/or annoying bugs. Please use this as a personal filter when reviewing the bugs. :-) Thanks, -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CustomSQLDBReceiver
We should do another 1.3 alpha release around the same time we release 1.2.11. -Mark -Original Message- From: Scott Deboy [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 6:34 PM To: Log4J Users List Subject: RE: CustomSQLDBReceiver CustomSQLDBReceiver was left out of the db jar in the 1.3 alpha 6 release because of a problem with the ant script. I've fixed the ant problem so if you feel like building from CVS, the db jar will contain the class. The class is available with the 1.3 alpha 6 download - in src/java/org/apache/log4j/db - You could compile it and add it to your classpath set in chainsaw.bat, and it should work ok. 1.3 alpha 6 is available here: http://logging.apache.org/site/binindex.cgi Scott -Original Message- From: Tan Kah Siong [mailto:[EMAIL PROTECTED] Sent: Tue 6/14/2005 6:00 PM To: Log4J Users List Cc: Subject: RE: CustomSQLDBReceiver I had followed the instructions to loading the config file. I had the error encountered attached. It seems that the SQLreceiver class cannot be found. The program was run using the provided chainsaw.bat. Thanks --- Scott Deboy [EMAIL PROTECTED] wrote: 1. The file-load menu items are provided as a way to process a log file created by a file appender configured to use XMLLayout. Instead, configure Chainsaw this way: Open Chainsaw Select the view-show application wide preferences menu In the 'automatic configuration url' field at the bottom, specify the URL to your config file. Example: file:///c:/mysql-chainsaw-config.xml Restart Chainsaw 2. Chainsaw does support custom fields and CustomSQLDBReceiver provides a way to pass them to Chainsaw. Customsqldbreceiver expects all properties to be combined into a single string and returned as the PROPERTIES field in the SQL statement. This field is then parsed into the individual properties, thus the need for concat. Ugly but it works. If you feel like contributing a patch to improve the receiver in this area, please do! 3. There is a JNDIConnectionSource, which can be pooled. See http://logging.apache.org/log4j/docs/api- 1.3/org/apache/log4j/db/JNDIConnectionSource.html Scott -Original Message- From: Tan Kah Siong [mailto:[EMAIL PROTECTED] Sent: Tue 6/14/2005 2:12 AM To: log4j-user@logging.apache.org Cc: Subject:CustomSQLDBReceiver Hi, I am interested in using my mssql server as a base for Chainsaw log viewer. I had tried to do this after reading the documentation and encountered the following problems and questions. I had edited the Example Receiver configuration by deleting away all plugins except CustomDBReceiver. I also changed the connection source's password, user, driver and url to my requirements. Lastly i used a sql statement that would utilise the compulsary fields as stated in the documentation, without the concat part. The sql server i used is setup with the corresponding fields. I fired up ChainSaw and loaded the edited xml file through the Load Log4J File menu, however, nothing happens after that, no loading nor errors. I also see no network activity that indicates attempts to contact sql server. 1) Is there any step i missed or gone wrong? 2) I noted that chainsaw support only the documented fields, can it support other custom fields. ?Using concat? 3) How would i use pooled connections with ChainSaw? Please advice. __ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ - 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] __ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [INFO] Log4j Release Overview
Yes. As I said, we will be determining the set of tasks to be completed for the release, and will start doing more releases. -Mark -Original Message- From: Ricardo Trindade [mailto:[EMAIL PROTECTED] Sent: Thursday, May 19, 2005 8:34 AM To: Log4J Users List Subject: Re: [INFO] Log4j Release Overview Hi, I would suggest, if possible, more frequent snapshot/alpha builds of 1.3 branch. thanks Ricardo Mark Womack wrote: The log4j committers recently voted to accept the following release schedule for future versions of log4j: 1) Release 1.2.11 with JMS build fix. Timeframe is immediate, within the next week. We should have a build candidate by this Monday, with the release before the end of the week. Andy McBride reported that the JMS related classes were not part of the last build and submitted a patch to fix the build problem. 2) Release a 1.2.12 version with the TRACE change plus other major bug fixes, keeping it within reason. Timeframe is within a month of the 1.2.11 release. We will be determining the final set of bug fixes to include by the end of next week. We want to fix major problems that do not require api or structural changes. If you have a suggestion, please let us know asap. Reported bugs with understandable descriptions AND patches will get priority. We make no guarantees, but we want to hear about them. We are going to move on this quick so we can focus on the v1.3 release (below). 3) Release a 1.3 version based on the current main branch. Timeframe: release of first final version by 10/2005. v1.3 is the next major release of log4j. There are going to be many changes, some breaking, from the current v1.2 version. We will be posting more information about this in the coming weeks. In particular, we are working on a jDiff report that will more clearly show the differences in the api between 1.2.x and the new 1.3 version. This version has been a long time coming, and the log4j team is committing to getting it out by October. There have already been some early alpha releases, and there will be beta releases as we move forward. It is expected that 1.2.12 will be the last release on the 1.2 branch, and all future effort will be focused on version 1.3. If you have any comments or questions, please post them. - The log4j committers - 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]
[INFO] Log4j Release Overview
The log4j committers recently voted to accept the following release schedule for future versions of log4j: 1) Release 1.2.11 with JMS build fix. Timeframe is immediate, within the next week. We should have a build candidate by this Monday, with the release before the end of the week. Andy McBride reported that the JMS related classes were not part of the last build and submitted a patch to fix the build problem. 2) Release a 1.2.12 version with the TRACE change plus other major bug fixes, keeping it within reason. Timeframe is within a month of the 1.2.11 release. We will be determining the final set of bug fixes to include by the end of next week. We want to fix major problems that do not require api or structural changes. If you have a suggestion, please let us know asap. Reported bugs with understandable descriptions AND patches will get priority. We make no guarantees, but we want to hear about them. We are going to move on this quick so we can focus on the v1.3 release (below). 3) Release a 1.3 version based on the current main branch. Timeframe: release of first final version by 10/2005. v1.3 is the next major release of log4j. There are going to be many changes, some breaking, from the current v1.2 version. We will be posting more information about this in the coming weeks. In particular, we are working on a jDiff report that will more clearly show the differences in the api between 1.2.x and the new 1.3 version. This version has been a long time coming, and the log4j team is committing to getting it out by October. There have already been some early alpha releases, and there will be beta releases as we move forward. It is expected that 1.2.12 will be the last release on the 1.2 branch, and all future effort will be focused on version 1.3. If you have any comments or questions, please post them. - The log4j committers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging http session identifying information
If I understand correctly, you want to set session/user specific information per request? Since the MDC is stored in ThreadLocal, I think you will need to use a servlet filter to set and unset the MDC for each request. And yes, how threads are assigned to handle requests, etc is very container specific. So, setting and unsetting the MDC with each request is a good thing. I cannot remember offhand if there is already an MDC related servlet filter in the log4j-sandbox. You might want to take a quick look and use it as an example. -Mark - Original Message - From: Mark Lybarger [EMAIL PROTECTED] To: log4j-user@logging.apache.org Sent: Wednesday, May 18, 2005 5:47 AM Subject: logging http session identifying information I'm looking for a method to log http session information in our log4j logging. we want to be able to trace logging to a particular session. For instance, when a user reports having trouble, we would like to see what they did on the web site. We have a thread id being logged with each log, but there's no way to tie the threads together into a session of activity. I've also read that it's very container specific as to weather or not the same thread is used for an entire servlet execution. I came across this note on using MDC for logging session information. http://ulc-community.canoo.com/snipsnap/space/Contributions/Integration+Snippets/Log4J+MDC+Integration It seems rather easy to extend to support any http session attributes that i might want to log (user id, etc). Are there other methods to easily log a session id or other information in our log4j logs? Are there drawbacks to the solution of using the MDC integration? One thing that wasn't very clear with the MDC integration was where to put the setup code in an servlet container environment. We're using a startup servlet in all our web apps. Would we need this in each web app's startup servlet? Thanks! ~mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [INFO] Log4j Release Overview
The version number is 1.2.12, not 1.2.1.2, so 1.2.12 will be a newer version than 1.2.8. BTW, the latest released version is 1.2.9. Since we have not decided on the complete set of bug fixes yet, I can't answer this with complete certainty. It will contain the change to support a new level, TRACE, one level below DEBUG. -Mark -Original Message- From: Chennamaraja, Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 10:42 AM To: Log4J Users List Subject: RE: [INFO] Log4j Release Overview So what's the difference between 1.2.8 and 1.2.12 versions?, are we going back on version numbers?. I am confused srini -Original Message- From: Mark Womack [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 12:34 PM To: log4j-user@logging.apache.org Subject: [INFO] Log4j Release Overview The log4j committers recently voted to accept the following release schedule for future versions of log4j: 1) Release 1.2.11 with JMS build fix. Timeframe is immediate, within the next week. We should have a build candidate by this Monday, with the release before the end of the week. Andy McBride reported that the JMS related classes were not part of the last build and submitted a patch to fix the build problem. 2) Release a 1.2.12 version with the TRACE change plus other major bug fixes, keeping it within reason. Timeframe is within a month of the 1.2.11 release. We will be determining the final set of bug fixes to include by the end of next week. We want to fix major problems that do not require api or structural changes. If you have a suggestion, please let us know asap. Reported bugs with understandable descriptions AND patches will get priority. We make no guarantees, but we want to hear about them. We are going to move on this quick so we can focus on the v1.3 release (below). 3) Release a 1.3 version based on the current main branch. Timeframe: release of first final version by 10/2005. v1.3 is the next major release of log4j. There are going to be many changes, some breaking, from the current v1.2 version. We will be posting more information about this in the coming weeks. In particular, we are working on a jDiff report that will more clearly show the differences in the api between 1.2.x and the new 1.3 version. This version has been a long time coming, and the log4j team is committing to getting it out by October. There have already been some early alpha releases, and there will be beta releases as we move forward. It is expected that 1.2.12 will be the last release on the 1.2 branch, and all future effort will be focused on version 1.3. If you have any comments or questions, please post them. - The log4j committers - 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]
RE: logging http session identifying information
There is an example of putting stored cookie information into the MDC. You could easily modify it to use information from the session instead. http://cvs.apache.org/viewcvs.cgi/logging-log4j-sandbox/src/java/org/apache/ log4j/servlet/CookieMDCFilter.java?view=markup It doesn't do anything to remove the MDC information after the next filter in the filter chain completes, so it might be a good idea to do that. That way you don't have wayward MDC info sticking around in the thread local getting reported later in some unrelated request context. I would do that in a final block if possible to guarantee it gets removed. hth, -Mark -Original Message- From: Mark Lybarger [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 6:19 PM To: Log4J Users List Subject: Re: logging http session identifying information i want to log the session id, and any other info from the session that i choose so that i can sort my logs per session. i'll check out the sandbox. On 5/18/05, Mark Womack [EMAIL PROTECTED] wrote: If I understand correctly, you want to set session/user specific information per request? Since the MDC is stored in ThreadLocal, I think you will need to use a servlet filter to set and unset the MDC for each request. And yes, how threads are assigned to handle requests, etc is very container specific. So, setting and unsetting the MDC with each request is a good thing. I cannot remember offhand if there is already an MDC related servlet filter in the log4j-sandbox. You might want to take a quick look and use it as an example. -Mark - Original Message - From: Mark Lybarger [EMAIL PROTECTED] To: log4j-user@logging.apache.org Sent: Wednesday, May 18, 2005 5:47 AM Subject: logging http session identifying information I'm looking for a method to log http session information in our log4j logging. we want to be able to trace logging to a particular session. For instance, when a user reports having trouble, we would like to see what they did on the web site. We have a thread id being logged with each log, but there's no way to tie the threads together into a session of activity. I've also read that it's very container specific as to weather or not the same thread is used for an entire servlet execution. I came across this note on using MDC for logging session information. http://ulc- community.canoo.com/snipsnap/space/Contributions/Integration+Snippets/Log4 J+MDC+Integration It seems rather easy to extend to support any http session attributes that i might want to log (user id, etc). Are there other methods to easily log a session id or other information in our log4j logs? Are there drawbacks to the solution of using the MDC integration? One thing that wasn't very clear with the MDC integration was where to put the setup code in an servlet container environment. We're using a startup servlet in all our web apps. Would we need this in each web app's startup servlet? Thanks! ~mark - 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]
RE: log4j stops logging at console
JBoss, by current design, only provides for one logging context (ie
LoggerRepository). On top of that, the JBoss log4j.xml also sets up a
special CONSOLE appender that maps the System.out and System.err streams.
If you do any kind of configuration after JBoss starts up that affects the
console appender OR affects loggers that have been defined in the JBoss
log4j.xml file, then it will affect the output to the log files. Especially
Console, do not mess with Console. Also, if your log4j code ever calls
LoggerRepository.shutdown() during a redeploy, then logging will be hosed as
well.
JBoss really needs to provide a better mechanism to allowing web apps and
ejb's to do their own logging.
Log4j does provide some layering of configuration where you can set up
your own loggers and appenders as long as they are not references by the
first/base configuration file. Or you can just add your logging stuff to
the JBoss log4j.xml file directly.
You may also find the following link useful, but I don't know if anyone has
gotten to work correctly in JBoss or not. Seems to me that to be completely
efficient, it would need to be supported pretty deep in the JBoss log4j
initialization.
http://www.qos.ch/logging/sc.jsp
-Mark
-Original Message-
From: Clandes Tino [mailto:[EMAIL PROTECTED]
Sent: Monday, May 16, 2005 6:51 AM
To: log4j-user@logging.apache.org
Subject: log4j stops logging at console
Hello all.
I am facing the problem with log4j usage in two
separate applications.
I am using CONSOLE appenders for both of them.
Applications are started separately (in two shell
windows). The first app (App1) is assembled as EAR and
deployed under JBoss (it uses log4j.jar from
JBoss/server/default/lib and initializes log4j through
MBean, where appenders and loggers are configured).
Here is the method in MBean that configures log4j in
App1:
---
private void initLog4j() throws ConfigurationException
{
final Properties props = new Properties();
props.setProperty(log4j.category.com.myapp,
DEBUG, CONSOLE, FILE);
props.setProperty(log4j.appender.CONSOLE,org.apache.log4j.ConsoleAppend
er);
props.setProperty(log4j.appender.CONSOLE.layout,org.apache.log4j.Patter
nLayout)
props.setProperty(log4j.appender.CONSOLE.layout.ConversionPattern,%d{IS
O8601}
%-5p [%c{1}] [%X{user}] - %m%n);
props.setProperty(log4j.appender.FILE,org.apache.log4j.RollingFileAppen
der);
props.setProperty(log4j.appender.FILE.File,
getConfigurationSetting(LOG_FILE));
props.setProperty(log4j.appender.FILE.MaxFileSize,
getConfigurationSetting(MAX_FILE_SIZE));
props.setProperty(log4j.appender.FILE.MaxBackupIndex,
getConfigurationSetting(MAX_BACKUP_FILE));
props.setProperty(log4j.appender.FILE.layout,org.apache.log4j.PatternLa
yout);
props.setProperty(log4j.appender.FILE.layout.ConversionPattern,%d{ISO86
01}
%-5p [%c{1}] [%X{user} %X{ip} %X{userAgent}] -
%m%n);
PropertyConfigurator.configure(props);
}
App1 uses A.jar and B.jar from App2 in compilation and
runtime. Both jars are placed in sar archive and
deployed in default/deploy folder under Jboss.
The other (App2) is RMI Server application deployed
separately (it uses another log4j-1.2.8.jar placed in
its classpath). A.jar and B.jar are in its classpath.
App2 configures log4j by log4j properties file:
log4j.category.CONSOLE = , aCONSOLE
log4j.appender.aCONSOLE =
org.apache.log4j.ConsoleAppender
log4j.additivity.CONSOLE=false
log4j.appender.aCONSOLE.ImmediateFlush=true
log4j.appender.aCONSOLE.layout=org.apache.log4j.PatternLayout
--
Both applications are physically on the same machine.
The problem occurs when some class from App1 invokes a
class from B.jar. Then logging disappears from console
window of App1. No further message in log appears.
However logging into file works OK.
My question is:
What can cause such behavior?
Thanx for the hint in advance.
Best regards
Milan
___
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
-
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]
test, please ignore
Testing. For some reason my messages to log4j mailing lists are taking a while to post. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: log4j stops logging at console
JBoss, by current design, only provides for one logging context (ie
LoggerRepository). On top of that, the JBoss log4j.xml also sets up a
special CONSOLE appender that maps the System.out and System.err streams.
If you do any kind of configuration after JBoss starts up that affects the
console appender OR affects loggers that have been defined in the JBoss
log4j.xml file, then it will affect the output to the log files. Especially
Console, do not mess with Console. Also, if your log4j code ever calls
LoggerRepository.shutdown() during a redeploy, then logging will be hosed as
well.
JBoss really needs to provide a better mechanism to allowing web apps and
ejb's to do their own logging.
Log4j does provide some layering of configuration where you can set up
your own loggers and appenders as long as they are not references by the
first/base configuration file. Or you can just add your logging stuff to
the JBoss log4j.xml file directly.
You may also find the following link useful, but I don't know if anyone has
gotten to work correctly in JBoss or not. Seems to me that to be completely
efficient, it would need to be supported pretty deep in the JBoss log4j
initialization.
http://www.qos.ch/logging/sc.jsp
-Mark
-Original Message-
From: Clandes Tino [mailto:[EMAIL PROTECTED]
Sent: Monday, May 16, 2005 6:51 AM
To: log4j-user@logging.apache.org
Subject: log4j stops logging at console
Hello all.
I am facing the problem with log4j usage in two
separate applications.
I am using CONSOLE appenders for both of them.
Applications are started separately (in two shell
windows). The first app (App1) is assembled as EAR and
deployed under JBoss (it uses log4j.jar from
JBoss/server/default/lib and initializes log4j through
MBean, where appenders and loggers are configured).
Here is the method in MBean that configures log4j in
App1:
---
private void initLog4j() throws ConfigurationException
{
final Properties props = new Properties();
props.setProperty(log4j.category.com.myapp,
DEBUG, CONSOLE, FILE);
props.setProperty(log4j.appender.CONSOLE,org.apache.log4j.ConsoleAppend
er);
props.setProperty(log4j.appender.CONSOLE.layout,org.apache.log4j.Patter
nLayout)
props.setProperty(log4j.appender.CONSOLE.layout.ConversionPattern,%d{IS
O8601}
%-5p [%c{1}] [%X{user}] - %m%n);
props.setProperty(log4j.appender.FILE,org.apache.log4j.RollingFileAppen
der);
props.setProperty(log4j.appender.FILE.File,
getConfigurationSetting(LOG_FILE));
props.setProperty(log4j.appender.FILE.MaxFileSize,
getConfigurationSetting(MAX_FILE_SIZE));
props.setProperty(log4j.appender.FILE.MaxBackupIndex,
getConfigurationSetting(MAX_BACKUP_FILE));
props.setProperty(log4j.appender.FILE.layout,org.apache.log4j.PatternLa
yout);
props.setProperty(log4j.appender.FILE.layout.ConversionPattern,%d{ISO86
01}
%-5p [%c{1}] [%X{user} %X{ip} %X{userAgent}] -
%m%n);
PropertyConfigurator.configure(props);
}
App1 uses A.jar and B.jar from App2 in compilation and
runtime. Both jars are placed in sar archive and
deployed in default/deploy folder under Jboss.
The other (App2) is RMI Server application deployed
separately (it uses another log4j-1.2.8.jar placed in
its classpath). A.jar and B.jar are in its classpath.
App2 configures log4j by log4j properties file:
log4j.category.CONSOLE = , aCONSOLE
log4j.appender.aCONSOLE =
org.apache.log4j.ConsoleAppender
log4j.additivity.CONSOLE=false
log4j.appender.aCONSOLE.ImmediateFlush=true
log4j.appender.aCONSOLE.layout=org.apache.log4j.PatternLayout
--
Both applications are physically on the same machine.
The problem occurs when some class from App1 invokes a
class from B.jar. Then logging disappears from console
window of App1. No further message in log appears.
However logging into file works OK.
My question is:
What can cause such behavior?
Thanx for the hint in advance.
Best regards
Milan
___
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
-
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]
RE: log4j 1.3 update needed...
So noted. Would anyone be interested in logging a bug? Also, we are in the process of determining the release schedule for v1.3 going forward. Nothing is solid yet, but we are looking at a release of v1.3 before the end of the year, with a beta release around late summer. -Mark -Original Message- From: Juan Jose Garcia Lau [mailto:[EMAIL PROTECTED] Sent: Monday, May 09, 2005 1:57 PM To: Log4J Users List Subject: RE: log4j 1.3 update needed... Best regards developers: I agree with Hein, in the next release, please make an option to turn off the log4j internal output log. Thanks, Juan -Original Message- From: Hein Meling [mailto:[EMAIL PROTECTED] Sent: Domingo, 08 de Mayo de 2005 03:12 p.m. To: log4j-user@logging.apache.org Subject: log4j 1.3 update needed... Dear log4j developers. I would really like to encourage you to release a new 1.3 alpha7 or beta1 something ASAP, as alpha6 has been out there for too long without any updates; and I don't want to spend my time trying to compile a cvs version, since it does not appear to be straight forward with maven or some other simple means (that is, I don't want to hunt the net for jar files...) In particular, I find alpha6 quite useless with all its log4j internal log output polluting the output, similar to this: log4j:INFO Creating new logger [jgroup.util.log.Eventlogger] in repository [default]. Maybe its possible to turn them off; (have only seen messages on the list stating otherwise)... Thanks, Hein - 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]
