gmane.comp.apache.logging.log4cxx.user

Re: Socket and XMLSocketReceiver

Stefan Borovac — 2008-08-19T18:02:32

Hi Dale, thanks for your answer and the usefull tips. I have expected something like this but 2 1/2 years since the last Chainsaw release is quite a bit too long. We will see if we use Chainsaw at all. Cheers Stefan Dale King wrote:

Re: root node of configuration file

Jacob L. Anawalt — 2008-08-19T16:59:22

You could modify CONFIGURATION_TAG and other code in domconfigurator.cpp and do a custom build, but unless only you are going to be dealing with the resulting app, and make it clear that it's not following log4j.dtd, it may bite someone in the future. I use multiple configuration files in a configuration directory.

Re: Socket and XMLSocketReceiver

Dale King — 2008-08-19T15:22:17

On Tue, Aug 19, 2008 at 9:26 AM, Stefan.Borovac< at >t-online.de < Stefan.Borovac< at >t-online.de> wrote: Yes the following will do it for the current thread. It is on a per thread basis so needs to be done per thread. log4cxx::MDC::put( "application", "my application name" ); This is a known version compatibility issue with the released version of Chainsaw. The current version of Log4j is the 1.2.x branch which is what Log4Cxx is a port of. A long while back work was started on a new 1.3 branch of Log4J. This branch was later abandoned and most of the features ported to the 1.2.x branch. There are differences between 1.2 and 1.3 that mean that 1.2 serialized location info and MDC properties do not deserialize correctly in 1.3. The problem is that the currently released version of Chainsaw is built with the 1.3 branch of Log4J. For now stick to XMLSocketAppender. Feel free to complain loudly over on the Log4J forums about this. I find it unbelievable that there has been no new release of Chainsaw to fix this since the release of Chainsaw 2 1/2 years ago! You're welcome to try to build Chainsaw yourself against the 1.2 branch. Good luck, I've never been able to do it. Here is more info on this: http://markmail.org/message/ih7q5rgfckmlowaw#query:log4j%20chainsaw%20MDC+page:1+mid:ny52attu27fglhnl+state:results

Re: root node of configuration file

Dale King — 2008-08-19T15:00:44

Not without changing the software. I don't understand why you would want this. You say that it contains other information. The parser ignores any child elements of the configuration that are not one of the tags it knows about so you can put other information within the configuration. On Tue, Aug 19, 2008 at 2:21 AM, Madhu Gowda yahoo.com>wrote:

Socket and XMLSocketReceiver

2008-08-19T13:26:46

Hi All, I'am using log4cxx 0.10.0 and Chainsaw v2 as a server. On the Chainsaw side I'am using a SocketReceiver and a XMLSocketReceiver. Now I have three beginner questions concerning this setup. 1) The events logged by the XMLSocketReceiver are all written to the "chainsaw-log" tab. This is somehow ugly. Is it possible to set the "Application property" such that the XML messages are going to a different tab? I have found only vague descriptions on setting this property (even on the name of the key). 2) Question (1) is also a problem for the SocketReceiver, well different tabs are open for different remote hosts, but an application name is still missing. 3) While it was possible to send the "locationInfo" with the XMLSocketAppender, the same does not work on the SocketAppender/SocketReceiver pair, although the C++ code suggest that the location info is serialized. Any clou here? Any help is welcome! Cheers Stefan P.S.: Here is the Chainsaw config. And here the C++ config on the client side: // XML socket stuff +++++++++++++++++++++++++++++++++++++++++++++++ XMLSocketAppenderPtr myXMLSocketAppender( new XMLSocketAppender( LOG4CXX_STR("XXX.XXX.XXX.XXX"), 4448 ) ); XMLLayoutPtr myXMLLayout( new XMLLayout() ); myXMLLayout->setLocationInfo(true); myXMLSocketAppender->setLayout(myXMLLayout); myXMLSocketAppender->activateOptions(pool); // plain socket stuff +++++++++++++++++++++++++++++++++++++++++++++++ SocketAppenderPtr mySocketAppender( new SocketAppender( LOG4CXX_STR("XXX.XXX.XXX.XXX"), 4560 ) ); mySocketAppender->activateOptions(pool); logger->addAppender(mySocketAppender); logger->addAppender(myXMLSocketAppender); logger->setLevel(log4cxx::Level::getDebug());

root node of configuration file

Madhu Gowda — 2008-08-19T06:21:37

Hi all, I am using a xml file to configure the logger. Here, the xml file needs the root node as or . I donot want the root node to be named as or , as my configuration file contains some other information also. Is this possible to keep the root node something other than or . Regards, Madhu Gowda

RE: apr-util-expat

Mehta, Jenica — 2008-08-19T06:17:52

Thank you. When I build log4cxx using Visual Studio, it does not generate expat lib instead I see "xml" library getting generated. So is it possible that log4cxx may not depend on expat and may depend on xml.lib? Or do I need to use some flag to explicitly let log4cxx use expat? Regards. -----Original Message----- From: Curt Arnold [mailto:carnold< at >apache.org] Sent: Friday, August 15, 2008 11:50 PM To: Log4CXX User Subject: Re: apr-util-expat On Aug 13, 2008, at 9:19 AM, Mehta, Jenica wrote: Not quite sure what you are asking and seems like an APR question anyway. If you are building APR using configure and make, it will use a previously installed expat. If you are building using Visual Studio, apr-util has an embedded copy of expat that it will compile.

RE: Is this a bug or user error?

Peter Steele — 2008-08-18T16:14:04

I've heard of this SocketServer. I'll have to check it out. Thanks. From: renny.koshy< at >rubixinfotech.com [mailto:renny.koshy< at >rubixinfotech.com] Sent: Monday, August 18, 2008 7:44 AM To: Log4CXX User Subject: RE: Is this a bug or user error? Peter - We've had the exact same requirement on platform we did, which used Log4j... and ended up running the included "SocketServer" app and then logging everything to the socket-server, which actually wrote out the combined file. Renny Koshy President & CEO -------------------------------------------- Rubix Information Technologies, Inc. www.rubixinfotech.com "Peter Steele" maxiscale.com> 08/18/2008 10:35 AM Please respond to "Log4CXX User" logging.apache.org> To "Log4CXX User" logging.apache.org> cc Subject RE: Is this a bug or user error? A multi-file-appender would be a great addition. I guess in the meantime the only solution is to either have all of the applications log to their own log file or implement a log server. We clearly can't continue to use the configuration we have now... -----Original Message----- From: Curt Arnold [mailto:carnold< at >apache.org] Sent: Friday, August 15, 2008 11:27 AM To: Log4CXX User Subject: Re: Is this a bug or user error? On Aug 15, 2008, at 10:59 AM, Peter Steele wrote: log4cxx's RFAs mimics log4j's RFAs and having multiple independent applications attempt to write to the same location is a common misconfiguration problem in the log4j world. There is no mechanism (at least using java.io) to detect the situation, so the best we can do is to tell people not to do it. You are apparently running on non-Windows platform. What is occurring is that one application rolls over renaming the previous log file and creates the new log file, when other applications decide that it is time to roll over, then fail to create the new log file and continue to write to their old handle (which has been renamed since they originally opened it). There has been a long stalled initiative to develop a MultiFileAppender for log4j which may handle the situation more gracefully (not its main objective), but that development has been stalled for a year or so.

RE: Is this a bug or user error?

2008-08-18T14:43:54

Peter - We've had the exact same requirement on platform we did, which used Log4j... and ended up running the included "SocketServer" app and then logging everything to the socket-server, which actually wrote out the combined file. Renny Koshy President & CEO -------------------------------------------- Rubix Information Technologies, Inc. www.rubixinfotech.com "Peter Steele" maxiscale.com> 08/18/2008 10:35 AM Please respond to "Log4CXX User" logging.apache.org> To "Log4CXX User" logging.apache.org> cc Subject RE: Is this a bug or user error? A multi-file-appender would be a great addition. I guess in the meantime the only solution is to either have all of the applications log to their own log file or implement a log server. We clearly can't continue to use the configuration we have now... -----Original Message----- From: Curt Arnold [mailto:carnold< at >apache.org] Sent: Friday, August 15, 2008 11:27 AM To: Log4CXX User Subject: Re: Is this a bug or user error? On Aug 15, 2008, at 10:59 AM, Peter Steele wrote: log4cxx's RFAs mimics log4j's RFAs and having multiple independent applications attempt to write to the same location is a common misconfiguration problem in the log4j world. There is no mechanism (at least using java.io) to detect the situation, so the best we can do is to tell people not to do it. You are apparently running on non-Windows platform. What is occurring is that one application rolls over renaming the previous log file and creates the new log file, when other applications decide that it is time to roll over, then fail to create the new log file and continue to write to their old handle (which has been renamed since they originally opened it). There has been a long stalled initiative to develop a MultiFileAppender for log4j which may handle the situation more gracefully (not its main objective), but that development has been stalled for a year or so.

RE: Is this a bug or user error?

Peter Steele — 2008-08-18T14:35:19

A multi-file-appender would be a great addition. I guess in the meantime the only solution is to either have all of the applications log to their own log file or implement a log server. We clearly can't continue to use the configuration we have now... -----Original Message----- From: Curt Arnold [mailto:carnold< at >apache.org] Sent: Friday, August 15, 2008 11:27 AM To: Log4CXX User Subject: Re: Is this a bug or user error? On Aug 15, 2008, at 10:59 AM, Peter Steele wrote: log4cxx's RFAs mimics log4j's RFAs and having multiple independent applications attempt to write to the same location is a common misconfiguration problem in the log4j world. There is no mechanism (at least using java.io) to detect the situation, so the best we can do is to tell people not to do it. You are apparently running on non-Windows platform. What is occurring is that one application rolls over renaming the previous log file and creates the new log file, when other applications decide that it is time to roll over, then fail to create the new log file and continue to write to their old handle (which has been renamed since they originally opened it). There has been a long stalled initiative to develop a MultiFileAppender for log4j which may handle the situation more gracefully (not its main objective), but that development has been stalled for a year or so.

RE: RollingFileAppender question

Peter Steele — 2008-08-16T18:13:32

Hmmm, that justmight do the trick. Thanks for the suggestion... From: Chris D'Annunzio [mailto:ChrisD< at >verdiem.com] Sent: Friday, August 15, 2008 11:00 AM To: Log4CXX User Subject: RE: RollingFileAppender question You could manually trigger a rollover when the application starts up. We do something similar in our application when the user wants to clear the log files. log4cxx::LoggerPtr pLogger = log4cxx::Logger::getRootLogger(); log4cxx::AppenderPtr pAppender = pLogger->getAppender(LOG_FILEAPPENDER_NAME); if (pAppender) { // Down cast so we have access tot he rolling file appender's methods log4cxx::helpers::ObjectPtrT pRFAppender = pAppender; log4cxx::helpers::Pool pool; pRFAppender->rollover(pool); } That will trigger a log file rollover. So, you could configure the appender with Append = true and then trigger a rollover when the application first starts up. You might need a special case when the application starts for the first time if you don't want an extra empty log file, but hope this gets you closer. -Chris ________________________________ From: Peter Steele [mailto:psteele< at >maxiscale.com] Sent: Thursday, August 14, 2008 10:24 AM To: Log4CXX User Subject: RollingFileAppender question We are using a RollingFileAppender defined as follows: This works the way we want with one exception: When our app that uses this appender starts up it overwrites the existing log file. This is of course because we have Append set to false. What we'd like to have happen is that if there is an existing log file have a rollover occur immediately so that no log data is lost. Can that be setup or is our only option is to set Append to true?

Re: Is this a bug or user error?

Curt Arnold — 2008-08-15T18:26:52

On Aug 15, 2008, at 10:59 AM, Peter Steele wrote: log4cxx's RFAs mimics log4j's RFAs and having multiple independent applications attempt to write to the same location is a common misconfiguration problem in the log4j world. There is no mechanism (at least using java.io) to detect the situation, so the best we can do is to tell people not to do it. You are apparently running on non-Windows platform. What is occurring is that one application rolls over renaming the previous log file and creates the new log file, when other applications decide that it is time to roll over, then fail to create the new log file and continue to write to their old handle (which has been renamed since they originally opened it). There has been a long stalled initiative to develop a MultiFileAppender for log4j which may handle the situation more gracefully (not its main objective), but that development has been stalled for a year or so.

Re: apr-util-expat

Curt Arnold — 2008-08-15T18:20:15

On Aug 13, 2008, at 9:19 AM, Mehta, Jenica wrote: Not quite sure what you are asking and seems like an APR question anyway. If you are building APR using configure and make, it will use a previously installed expat. If you are building using Visual Studio, apr-util has an embedded copy of expat that it will compile.

RE: RollingFileAppender question

Chris D'Annunzio — 2008-08-15T18:00:12

You could manually trigger a rollover when the application starts up. We do something similar in our application when the user wants to clear the log files. log4cxx::LoggerPtr pLogger = log4cxx::Logger::getRootLogger(); log4cxx::AppenderPtr pAppender = pLogger->getAppender(LOG_FILEAPPENDER_NAME); if (pAppender) { // Down cast so we have access tot he rolling file appender's methods log4cxx::helpers::ObjectPtrT pRFAppender = pAppender; log4cxx::helpers::Pool pool; pRFAppender->rollover(pool); } That will trigger a log file rollover. So, you could configure the appender with Append = true and then trigger a rollover when the application first starts up. You might need a special case when the application starts for the first time if you don't want an extra empty log file, but hope this gets you closer. -Chris ________________________________ From: Peter Steele [mailto:psteele< at >maxiscale.com] Sent: Thursday, August 14, 2008 10:24 AM To: Log4CXX User Subject: RollingFileAppender question We are using a RollingFileAppender defined as follows: This works the way we want with one exception: When our app that uses this appender starts up it overwrites the existing log file. This is of course because we have Append set to false. What we'd like to have happen is that if there is an existing log file have a rollover occur immediately so that no log data is lost. Can that be setup or is our only option is to set Append to true?

Re: Is this a bug or user error?

Jacob L. Anawalt — 2008-08-15T16:18:37

Interesting that some fail to roll over and close the old file handle. I think it would be better to have individual processes write to a log server, either a log4cxx capable one that can read a config file and filter or a "dumb" one, and have a single log server write to the log file.

Is this a bug or user error?

Peter Steele — 2008-08-15T15:59:01

We use the DailyRollingAppender, defined as follows in our config file: Several applications log to the same log file using this appender. What's happening is when the rollover occurs at midnight, some processes still log to the original file, which has now been renamed, whereas others log to the main log file as they should. I'm suspecting that this is an error on our part and we should not have multiple processes all log to the same file, although I've heard that others do this. What's the solution?

Autodetection of libs and includes flags / Automake macro?

Heiko Klein — 2008-08-15T12:22:08

Hi, I would like to integrate lib4cxx into my project, which uses automake for the build-process. How can I automatically detect if lib4cxx is installed and which lib and include flags I have to use? I am thinking of either a nice automake .m4 macro like the find_apr.m4, or a config program, which gives the needed information (e.g. pkg-config or apr-config). Best regards, Heiko

RollingFileAppender question

Peter Steele — 2008-08-14T17:24:04

We are using a RollingFileAppender defined as follows: This works the way we want with one exception: When our app that uses this appender starts up it overwrites the existing log file. This is of course because we have Append set to false. What we'd like to have happen is that if there is an existing log file have a rollover occur immediately so that no log data is lost. Can that be setup or is our only option is to set Append to true?

apr-util-expat

Mehta, Jenica — 2008-08-13T14:19:41

Hi, Any idea if expat project inside apr-util, has a separate project called XML. Apr-util depends on expat libs or xml lib? Or under some condition? Jenica Mehta

Adapt an existing FileAppender

Eberhard, Markus (external — 2008-08-07T14:15:49

Hey *, I have found the following two lines of code to adapt an existing FileAppender: Appender* appender = Logger::getRootLogger()->getAppender ("RollingFile"); FileAppender* fa = dynamic_cast(appender); But when I try to implement this functionylity in my method I get always an dynamic_cast exception, here is my code snippet: std::string errorLogFile = "test.log"; const log4cxx::LogString rootLoggerFileAppenderName = LOG4CXX_STR("RootLoggerFileAppender"); ... std::wstring logFilePathName(errorLogFile.begin(), errorLogFile.end()); log4cxx::Appender* rootFileAppender = log4cxx::Logger::getRootLogger()->getAppender(rootLoggerFileAppenderName ); if(rootFileAppender == 0 || rootFileAppender == NULL) { log4cxx::LogString logStringFormat = LOG4CXX_STR("[%-5p] - %m%n"); log4cxx::LayoutPtr layout(new log4cxx::PatternLayout(logStringFormat)); rootFileAppender = new log4cxx::FileAppender(layout, logFilePathName, true); rootFileAppender->setName(LOG4CXX_STR("RollingFile")); log4cxx::Logger::getRootLogger()->addAppender(rootFileAppender);} /* the following dynamic_cast throws an exception */ try { dynamic_cast(rootFileAppender)->setFile(logFileP athName); } catch(...) { log4cxx::Logger::getRootLogger()->removeAppender(rootLoggerFileAppenderN ame); log4cxx::BasicConfigurator::configure(); LOG4CXX_ERROR(m_logger, "FileAppender couldn't be configured for root logger, invalid log file specified: " << errorLogFile); LOG4CXX_ERROR(m_logger, "A ConsoleAppender was added to the root logger instead of the FileAppender."); return 1; } Where is my bug? Thanks for any respons Markus

RE: Upgrading from 0.9.7 to 0.10.0 - Pool Information

Chris D'Annunzio — 2008-08-06T18:16:08

Thanks for the reply Curt. I understand how it works now. Best, Chris -----Original Message----- From: Curt Arnold [mailto:carnold< at >apache.org] Sent: Monday, August 04, 2008 11:01 PM To: Log4CXX User Subject: Re: Upgrading from 0.9.7 to 0.10.0 - Pool Information On Aug 1, 2008, at 4:39 PM, Chris D'Annunzio wrote: Pool parameters are a memory pool that is used for just that operation. No memory or other resource from that pool is expected to live beyond the duration of the call. You could either create a new subpool of the global pool for each call: log4cxx::helpers::Pool p; appender->activateOptions(p); or share the same pool between multiple calls: log4cxx::helpers::Pool p; // whatever loop you may already have in your program for(std::vector::interator iter = appenders.begin(); iter != appender.end(); iter++) { (*iter)->activateOptions(p); } The Pool constructor calls apr_pool_create() and the destructor calls apr_pool_destroy.