Re: Comments on HierarchyEventListener implementation details and other junk
On Sep 9, 2011, at 1:34 PM, Rhys Ulerich wrote:
For an MPI-based application where I needed to broadcast a
configuration from one MPI rank to all others, I have noticed the
following gotchas about log4cxx's trunk innards. Not questions so
much as requests for comments or to help some other soul searching
this mailing list in the future...
0) Thank you for log4cxx. It is a great tool.
1) If one wants to write a custom HierarchyEventListener, at
declaration time both 'using namespace log4cxx' and 'using namespace
log4cxx::helpers' statements need to be in effect (I think) due to the
Object hierarchy macros. For example, anyone #including a custom
class like the following must (I think) necessarily pollute their
names with log4cxx implementation details:
class SubversiveASHEL : public virtual spi::HierarchyEventListener,
public virtual ObjectImpl
{
public:
DECLARE_LOG4CXX_OBJECT(SubversiveASHEL)
BEGIN_LOG4CXX_CAST_MAP()
LOG4CXX_CAST_ENTRY(SubversiveASHEL)
LOG4CXX_CAST_ENTRY(HierarchyEventListener)
END_LOG4CXX_CAST_MAP()
virtual void removeAppenderEvent(
const LoggerPtr, const AppenderPtr);
virtual void addAppenderEvent(
const LoggerPtr logger, const AppenderPtr appender);
};
Will have to look into that and dredge into the history. You would think that
it would not be necessary to have any log4cxx namespaces in scope, but might
have been forced to by the compilers at the time. All very murky at the moment.
Documentation about how to write one's own class that descends from
Object would be most helpful. Another possibility would be having an
abstract HierarchyEventListener base class from which one could
inherit.
If you'd like to put together a skeleton Wiki page with the questions that
you'd like addressed and put TODO's or something where you don't know, I and
possibly others would be willing to try to remember or research to find
answers. But I don't see me ever looking at a blank sheet of paper and deciding
that is what I want to spend my time on.
2) A FileInputStream/ByteBuffer combination works in (unadorned) chars
but a ByteArrayInputStream requires unsigned chars. This makes
reading a configuration file into memory using File (as 'char' data)
and then configuring via Properties::load (as 'unsigned char' data via
ByteArrayInputStream) tricky.
Any mismatch between signed chars and unsigned chars generally indicates that a
character transcoder is missing (or there is one that you didn't expect) and
would really not match if logchar was switched from char to wchar_t, things
would be even more mismatched. Java property files are defined as ISO 8559-1
regardless of platform encoding, hence they work in bytes since they don't want
someone else handling the translation from bytes to characters upstream.
3) It appears there's no way to use DOMConfigurator without having a
configuration file sitting on disk.
APR did not expose any obvious mechanism for parsing byte streams hence log4cxx
couldn't offer it. Looking at APR, doesn't look like that has changed.
4) The statement in LogManager's doxygen that When the LogManager
class is loaded into memory the default initialization procedure is
initiated should be clarified in some way. Maybe only when an
instance is created? Merely using LogManager::getLoggerRepository()
does not cause such an auto-configuration.
The doc is likely copied verbatim from log4j.
5) It would be helpful if the configuration file magic in
defaultconfigurator.cpp was exposed so that one can retrieve the
configpath to use for configuration. Currently the
configuration-finding and configuration-loading logic seemed joined at
the hip and one must extract it from that source.
If you have ideas, file a bug report with or without a patch.
6) LogLog::setQuietMode(true) followed by emitting a message followed
by LogLog::setQuietMode(false) can be used to eliminate the log4cxx:
Please initialize the log4cxx system properly message from appearing
but only if the message is of a high enough level to hit an appender.
LogManager::getLoggerRepository()-setConfigured(true) should also suppress the
message.
7) Finally, https://issues.apache.org/jira/browse/LOGCXX-385 contains
a patch which could be directly applied to trunk by someone with
committer access.
Thanks for the heads up.
Lastly, I plan to (at some point) write up a (possibly) sane
implementation of getting log4cxx initialized in a scalable way for an
MPI-based application. Without some monkeying, the auto-configuration
process causes every rank to hit the filesystem multiple times as each
rank gropes about for a configuration file. If you're interested in
the details, feel free to email me off list.
- Rhys
Re: How to get Local Time
log4c_category_log isn't a method in Apache log4cxx. I believe that you are using a different product and should ask your question on a forum for log4c users. On Aug 22, 2011, at 7:03 AM, pavan_734 wrote: log4c_category_log() is giving time in UTC even though I have set time zone to Indian Standard Time (IST) using ln -sf /usr/share/zoneinfo/Asia/Calcutta. How can I make the log4cxx to print logs as per local time zone. Should I need to add anything in the xml file. The current configuration is: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE log4c SYSTEM log4c version=1.2.1 layout name=basic type=dated/ config bufsize0/bufsize debug level=2/ nocleanup0/nocleanup reread1/reread /config category name=root priority=debug/ category name=my_module priority=info appender=logs/my_module.log / appender name=logs/my_module.log type=stream layout=dated / /log4c -- View this message in context: http://old.nabble.com/How-to-get-Local-Time-tp32310575p32310575.html Sent from the Log4cxx - Users mailing list archive at Nabble.com.
Re: RollingFileAppender file permission problem
On May 14, 2011, at 9:38 PM, Alex Huang (Gorilla) wrote: I should add that the very first log file is created with the non-root user as the owner and group and log messages are successfully written to it. It is the rolling over of the log file that has a permission problem. Alex I'm guessing that the logging request that triggers the rollover unfortunately has the user set to root and so the new file is created with those permissions. Perhaps you could provide a custom triggering policy and delay rolling over until a non-root request is received.
Re: Custom Appender
First. it would be best for you to define your custom appenders in a namespace
other than log4cxx.
Second, you declare a constructor, destructor and close method for
VirtualAppender, but you did not provide an implementation. Unless you
compiled and linked in a file that looked like:
#include VirtualAppender.h
log4cxx::VirtualAppender::VirtualAppender() {
}
log4cxx::VirtualAppender::~VirtualAppender() {
}
void log4cxx::VirtualAppender::close() {
}
Then the linker would be expected to complain that there was no implementation
provided.
Re: Static destruction fiasco?
On Feb 27, 2011, at 1:25 PM, Rhys Ulerich wrote:
Hi,
I've noticed that this little test program segfaults beautifully under 0.10
#include log4cxx/logger.h
log4cxx::LoggerPtr logger;
int main()
{
logger = log4cxx::Logger::getLogger(someName);
LOG4CXX_WARN(logger, Stuffstuffstuff);
// logger = 0;
return 0;
}
but if I uncomment the logger = 0 statement it runs just fine. Presumably
that's because logger = 0 forces the ObjectPtrT instance behind LoggerPtr to
destruct logger before other static destruction occurs.
That said, which of
1) Bug
2) Don't do that
does that segfault fall into?
Thanks,
Rhys
I'm guessing that you are running on a 64-bit Linux? The problem is that the
smart pointer assignment should be atomic and that APR did not have a pointer
exchange method at the time that the code (in this case
src/main/cpp/objectptr.cpp) was written. If the platform was not Windows and
not 32-bit, then APR mutexes were used to synchronize the operation (no longer
the case).
The problem occurs when APR is terminated prior to pointer destruction. This
will only occur when a static pointer is constructed prior to APR being
initialized. The pointer class assumes that APR has already been initialized
prior to the constructor. In general, you would expect to see code like:
log4cxx::LoggerPtr logger(log4cxx::Logger::getLogger(someName));
In that case, APR is initialized prior to to the LoggerPtr::LoggerPtr class, so
APR will be terminated after the LoggerPtr is destructed.
There are a couple of ways to avoid the issue that you've encountered:
a) Do not use the default constructor for static variables.
b) If you really want to use the default constructor for a static variable,
explicitly trigger APR initialization prior to the default constructors
APRInitializer::initialize();
log4cxx::LoggerPtr logger;
c) Use the SVN HEAD where 64-bit exchange no longer uses APR mutexes to
synchronize pointer exchanges.
Or any combination of the above.
Re: PropertyConfigurator::configure file encoding
Property files in Java are by definition in ISO-8859-1 which cannot support Chinese characters without using escape characters (see http://download.oracle.com/javase/6/docs/api/java/util/Properties.html). log4cxx follows this convention so that it is compatible with log4j configuration files. However, the issue is the substitution of the contents of the APPDATA environment variable into the evaluation of the configuration which should occur after the properties file in parsed and should happen in LogString (aka Unicode) space. I'm guessing things are failing since the evaluation of APPDATA does not match an existing directory and therefore the appender fails. It would be interesting to experiment with an environment variable for the file name (not the path) to see how the name is mangled. There are a couple of things that would be very useful to know: What operating system and version is being used? What is the default character encoding (control panel or $ locale charmap)? What settings are used to build log4cxx? What is the observed behavior when using environment variables for the filename (not the path)? What were the expected behavior? I'm pretty confident that the property files are correctly always interpreted as ISO-8859-1 regardless of the default encoding. log4cxx depends on APR to get the environment variables and for file IO, so something unexpected could be happening there or log4cxx could be mangling the substitution.
Re: ODBCAppender with sqlite3
I don't have any personal experience with the ODBCAppender at all and can't
recall ODBC+SQLite coming up before but I didn't check the archive myself.
Doing a quick search, it appears that ODBC support can be provided by several
third party software. Likely the configuration strings would vary depending on
which ODBC for SQLite implementation you used. Since, as far as I can tell,
they aren't socket-based, specifying ports seems at best meaningless.
Seems like a better path forward would be to write a custom appender for SQLite
bypassing a third-party ODBC driver. LOGCXX-101 was someone's effort to do
that for MySQL. If there were to be an appender add to log4cxx proper, I would
suggest using APR's database abstraction layer as suggested in LOGCXX-61.
https://issues.apache.org/jira/browse/LOGCXX-61
https://issues.apache.org/jira/browse/LOGCXX-101
On Jan 21, 2011, at 1:57 PM, Tavis Bones wrote:
I'm trying to figure out how to use the ODBCAppender using sqlite3. What
would the xml look like? What would be in the param of URL? Is that even
needed?
For example:
appender name=testSqliteAppender
class=org.apache.log4j.odbc.ODBCAppender
param name=URL
value=Driver={sqlite3};Server=localhost;Port=5432;Database=errorlog;Uid=sqlite3;Pwd=abc123;/
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=INSERT INTO errorlog
(errormessage) VALUES ('%d - %c - %p -%m')/
/layout
/appender
Re: Can't find custom appender
The likely suspect is that your appender is not being added to the registry of known appenders before the configuration is processed. Your appender should have a macro expansion like: IMPLEMENT_LOG4CXX_OBJECT(DailyRollingFileAppender) that contains the registration code. You can set a breakpoint there (depending on your debugger, you may need to manually expand) and on the configurator and see the order that they fire and whether the registration code gets called at all. If you have built your appender in a DLL or shared library, are you forcing the library to load to trigger the registration? On Nov 18, 2010, at 2:01 PM, Rob Outar wrote: I created a custom appender that extends RollingFileAppender, my class is located in a “test” namespace and the class name is TestAppender, in my xml file I have: appender name=FILE class=test. TestAppender But when I run, log4cxx says it cannot find appender… what am I missing? Best regards, Rob
Re: get method name of logging caller...
If you are using the LOG4CXX_DEBUG and similar macros and some of the more popular compilers, then you hopefully will get class and method information. If you transliterated java code and are just doing logger.debug(Msg), then that information is not available to you. The performance issue mentioned in log4j isn't applicable to log4cxx. In earlier version of log4j obtaining that information meant creating an exception, printing its stack trace to a memory stream and then parsing that stream to get the location. With the LOG4CXX_DEBUG macros, that information is added to the generated logging call at compile time. If you are able to see file and line, but not class and method, then explore extending __LOG4CXX_FUNC__ to support your compiler. On Oct 15, 2010, at 4:08 PM, Jacob L. Anawalt wrote: On 10/15/2010 5:53 AM, Thorsten Schöning wrote: Hello, is there any way to get the method name of the logging caller in the log message? As you say, the log4j docs document %M in the PatternLayout (while log4cxx does not) but caution against the inefficiency of it's use. Additionally The Complete Log4J Manual (a good document to have) points out that even in Java this information can be discarded by the compiler. In log4cxx %F and %L provide the file name and line number respectively, but that is because they can rely on the ubiquitious __FILE__ and __LINE__ macros. The LOG4CXX_LOCATION macro is documented to use __LOG4CXX_FUNC__ with a value of . If your compiler and flags support __FUNCTION__, you could work that into your message or change the definition of __LOG4CXX_FUNC__ and go on to implement %M. I haven't even glanced at the code to see where that's at. I just inflexibly typed the function name into a DEBUG message near the top of the message call, or sometimes used a NDC to track the call stack in debug logs. Good luck, -- Jacob Anawalt Gecko Software, Inc. janaw...@geckosoftware.com 435-752-8026
Re: rollingfileappender.h
log4cxx attempts to reproduce the appender set from log4j and log4j has two different RollingFileAppender classes, org.apache.log4j.RollingFileAppender and org.apache.log4j.rolling.RollingFileAppender. The latter was developed on the abandoned log4j 1.3 development branch, is now included in the extras companion to log4j and supports pluggable rollover strategies and triggering strategies. In log4cxx, log4cxx::RollingFileAppender (the analog to org.apache.log4j.RollingFileAppender) is implemented by delegation to log4cxx::rolling::RollingFileAppender (the analog to org.apache.log4j.rolling.RollingFileAppender). log4cxx::rolling::RollingFileAppender is the more general class and should be used unless you are porting configurations that used org.apache.log4j.RollingFileAppender. On Sep 15, 2010, at 4:25 AM, Fabian Jacquet wrote: Hi all, I need to configure a RollingFileAppender in the code of the program. But I see 2 definitions of RollingFileAppender (log4cxx::RollingFileAppender and log4cxx::rolling::RollingFileAppender) I don't know which definition to use. Do you know why we have 2 different definitions? And which to use?
Re: simple stringstream appender
STL streams maintain an internal state and would not be safe to use in an appender unless you used external synchronization and precomposed the message so that it was done as one operation. For example, if you did something like: os Hello World; if os was visible from another thread, you could have another thread inject something between Hello and World. We do however offer a STL stream-like interface for logging in log4cxx/stream.h. The current implementation does attempt to mimic as far as possible the semantics of STL streams which unfortunately can add a substantial performance penalty for features (like inserting format specifiers) that you may not use. If you really want to dive into it, search the archives for logstream. For an example of logstream usage, see src/examples/cpp/stream.cpp. On Aug 16, 2010, at 2:01 AM, andrejvanderzee wrote: Hi, I need an appended that writes to a stringstream. I want to be able to get the complete log after my CGI application is finished. Then I want to be able to access the complete log. How can I do this? I guess I could use a FileAppender and write to a temporary file and after my CGI application finishes read the log from the file. But, I prefer a stringstream solution. Thank you, Andrej -- View this message in context: http://old.nabble.com/simple-stringstream-appender-tp29447240p29447240.html Sent from the Log4cxx - Users mailing list archive at Nabble.com.
Re: hung for 2 hours when logging
Could it possibly be http://issues.apache.org/jira/browse/LOGCXX-317? If so, there is a patch there that may solve the issue. On Jun 11, 2010, at 11:58 PM, Yue Gao wrote: our server hung for 2 hours today. the log shows 2010-06-11 20:27:56,852 INFO - Saving data, INCREMENTAL, clock:15094434027 2010-06-11 20:27:56,852 INFO - 2010-06-11 23:07:50,223 INFO - Save Memory: 95 (9.05991e-05 M) 2010-06-11 23:07:50,223 INFO - Save Type: INCREMENTAL the code is LOG4CXX_INFO(logger_, Saving data, (saveType==DATA_SAVE_TYPE_COMPLETE?COMPLETE:INCREMENTAL), clock:clock-now()); balabal LOG4CXX_INFO(logger_, ); LOG4CXX_INFO(logger_, Save Memory: totSize (totSize/(float)(1024*1024) M)); LOG4CXX_INFO(logger_, Save Type: (saveType==DATA_SAVE_TYPE_INCREMENTAL?INCREMENTAL:COMPLETE)); the logger_ is initialized in the constructor as log4cxx::PropertyConfigurator::configureAndWatch(logger-w.cfg); logger_ = log4cxx::Logger::getLogger(World); and the config file is log4j.rootLogger=INFO, stdout, R log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d %-5p - %m%n log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=../log/fish-w.log log4j.appender.R.MaxFileSize=20MB log4j.appender.R.MaxBackupIndex=12 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%d %-5p - %m%n log4j.logger.diamond=INFO, FILE log4j.additivity.diamond=false log4j.appender.FILE = org.apache.log4j.DailyRollingFileAppender log4j.appender.FILE.File = ../log/diamond-w.log log4j.appender.FILE.DatePattern='.'-MM-dd log4j.appender.FILE.layout=org.apache.log4j.PatternLayout log4j.appender.FILE.layout.ConversionPattern=%d %-5p - %m%n there is no log rolling between log and Save Memory. the log shows it hung 2 hours between these two lines. Could anyone tell me why this happened? thanks
Re: error while linking with std::basic_string...::basic_string...(...)
The hex codes were intentional since they would give the expected character value even if compiled using a non-ASCII based encoding like EBCDIC. I'll try to pull the constants out into preprocessor macros and do a little #if(__BORLANDC__)
Re: Unable to build with VS2010
On May 12, 2010, at 8:23 AM, Julien Marbach wrote: Cory, I'm having the same probleme here. I have tried to correcte the c2252 errors by moving the declarations at manespace scope in state of class scope but other problems have arised I think my poor knowlege of c++ won't allow me to go further :-( Julien I vaguely remember looking at this with a beta edition of VS 2010 many months ago and it was a trickier problem than I had time for at the moment and never got back to it. Will try to look at it this evening.
Fwd: log4cxx 0.10.1 release plan (Re: link error in release mode with Visual Studio 2008 on log4cxx-user)
Cross posting on log4cxx-user since the question was asked there. Followup discussion should be on log4cxx-dev. Begin forwarded message: From: Curt Arnold carn...@apache.org Date: May 11, 2010 11:38:19 PM CDT To: Log4CXX Dev log4cxx-...@logging.apache.org Subject: log4cxx 0.10.1 release plan (Re: link error in release mode with Visual Studio 2008 on log4cxx-user) On May 10, 2010, at 8:44 AM, Reynolds, John wrote: Good to see you back Curt. Any dates on next release? I meant what executable format ( looked it up, it is Mach-O ). I knew it wasn't ELF even though it does use the FreeBSD tools. I've just logged http://issues.apache.org/jira/browse/LOGCXX-363 for a subsequent release. If there are bugs that really should be addressed before a release, mark it as a blocker on LOGCXX-363. If there are any bugs that you believe that you think are ready to go, please mention them on the list. Making VS 2010 happy would be one of them. I had really good intentions to work a log4cxx release as soon as I got through log4j 1.2.16, but that took much longer than I expected and there are still some aftermath issues that need to be cleaned up. Any help on prioritizing or checking the bug reports would be appreciated.
Re: link error in release mode with Visual Studio 2008
On May 10, 2010, at 4:52 AM, Reynolds, John wrote: As he is new to programming on windows, I suggested ant as it takes the build of log4cxx out of the Visual Studio as what he has built is corrupt in someway. It also enforces a clean build. Better to start in small steps. Build the DLL and then in Visual Studio setup a new clean project for his application. Things like __declspec are a pain to understand to people coming to it from a platform like ELF ( no idea what Darwin is ). The first line of this link explains the fact that a lib file can be for a static or DLL library. http://msdn.microsoft.com/en-us/library/a90k134d%28VS.80%29.aspx Thanks everybody for helping out. Encouraging to see the traffic though I have been distracted. Darwin is the open-sourced kernel that Mac OS/X is built upon.
Re: How to build a x64 library on windows with Visual Studio?
I do not believe that you should need to change any code. Been a while since I've tested a Win64 build, but I think the Ant driven VC++ build completed without issue. Don't recall the experience building within Visual Studio. Likely a project file issue. The .vcproj file in the release is generated from the Ant build script, not Visual Studio, so it might be missing some features. You could likely generate an empty project file in Visual Studio and then copy the guts of the .vcproj in the release and it would resolve the issue. _WIN32 is defined for all Windows builds including x86_64 and Itanium builds. _WIN64 is only defined for 64-bit builds. The only place you need to have _WIN64 is where the code differs between 64 and 32 bit Windows and in general that is usually places where the _WIN64 code would work with current 32-bit compilers but the 32-bit specific code will work with VC 6 and the like.
Re: LOG4CXX_DECODE_CHAR Crash on windows
Mismatching run-time libraries is a easy way to manufacture a crash. Basically any time one DLL tries to deallocate some resource allocated by a DLL using a different run time library (and that includes two DLLs that each use /MT since they have the own instances of the run- time library), bad things will happen. To build a DLL using the /MT run-time library and log4cxx, add the log4cxx source into your project and set the LOG4CXX_STATIC environment variable. If you try linking with a static library, you will only get the classes that you call directly. The ones that are expected to be present when the configuration is read will not have been linked into your DLL.
Re: Compilation Error -Log4cxx 0.10.0 on AS3 Redhat Linux (gcc2.96)]
When I checked the archives, it appears that you have reported this before. From log4cxx-user in July 12, 2008 I replied: gcc 2.96 was a prerelease version of gcc 3.x and has an incomplete implementation of the C++ Standard Template Library (see http://gcc.gnu.org/gcc-2.96.html ) . I have been able to get messagebuffer.h to compile by forward declaring std::ios_base and replacing std::basic_ostreamchar with std::ostream and similar changes, but there are also compilation failures in cachedateformat.cpp and properties.h and there may be others. I do not intend to work around gcc 2.96's limitation. gcc 2.96 is an odd-ball compiler disavowed by the gcc team. I'm not saying that I'd be opposed to integrating patches to work around its limitations as long as it doesn't compromise current and/or standard compliant compilers. However, there is nothing that motivates me to work through the issues with this compiler for you.
Re: problem with install log4cxx
On Nov 10, 2009, at 4:52 AM, Bajramovic, Ervin wrote: Hi everybody I want to build log4cxx I used the following configuration: ./autogen.sh ./configure CFLAGS=-O2 -s -mms-bitfields -march=i686 CXXFLAGS=-O2 -s -mms-bitfields -march=i686 --with-apr=/usr/local --with-apr- util=/usr/local make make install And i get this error: ... test -z /usr/local/include/log4cxx/private || /bin/mkdir -p /usr/ local/include/log4cxx/private /bin/install -c -m 644 ../../../../../src/main/include/log4cxx/ private/log4cxx_private.h log4cxx_private.h '/usr/local/include/ log4cxx/private' /bin/install: will not overwrite just-created `/usr/local/include/ log4cxx/private/log4cxx_private.h' with `log4cxx_private.h' make[6]: *** [install-privateincHEADERS] Error 1 Since you are failing to write to /usr/local, I'm guessing it is a permissions issue and you need to do sudo make install or the equivalent.
Re: multiple lines of output for the same logging event
On Aug 29, 2009, at 1:08 PM, vasile.jures...@sophia.inria.fr wrote: On Saturday 29 August 2009 21:01:37 deepak singh wrote: The reason could be you are initializing the logger multiple times. Can you send the code where you are initializing the logger and make sure that part of code is called just once during entire execution. Thanks Deepak You are calling BasicConfigurator::configure multiple times (once in each constructor). log4j and log4cxx configurations are cumulative, so each call attaches another appender to the root logger.
Re: this is a bug in the encoding procedure
On Aug 21, 2009, at 4:32 AM, shadow king wrote:
thanks for your reply.
BTW, Is there a convinent way to swtich off all the decoding
encoding thing completely? Because I don't want the performance
penalty imposed by the related function.
For me, I cound not see the benefit of using unicode as the
internal charset in log4cxx and I just want the log4cxx to log the
messages without any charset convertion.
On Fri, Aug 21, 2009 at 12:00 PM, Curt Arnold carn...@apache.org
wrote:
I'm thinking the constant should be 0x20, not 0x30. The code was an
attempt to be able to handle non-ASCII platforms like EBCDIC but
looks like it was mangled and was done without access to a non-ASCII
platform. Was just trying to do enough decoding to get the encoding
name to load a full charset.
You can hardwire the assumed encoding with
./configure --with-charset=utf-8
./configure --with-charset=usascii
./configure --with-charset=iso-8859-1
All three will replace conversion with glorified copy operations.
Specifying usascii will replace all non ASCII characters with a loss
character ('?') but if you specify an particular encoding for a file,
the resulting file will be valid.
utf-8 will blast characters directly into internal representation. If
you do not specify an encoding on any file appenders, the output file
will have the same charset as the platform. Filters, XML files,
SocketAppenders, and any thing with a specified encoding may be
invalid. However, if you just going straight through to a file, you
won't end up with loss characters.
iso-8859-1 will convert characters to utf-8. If you do not specify
any encoding, the output file will have the same encoding as the
platform. Won't result in illegal byte sequences like specifying
UTF-8, but any explicit encoding may result in character substitution.
Re: this is a bug in the encoding procedure
I'm thinking the constant should be 0x20, not 0x30. The code was an
attempt to be able to handle non-ASCII platforms like EBCDIC but looks
like it was mangled and was done without access to a non-ASCII
platform. Was just trying to do enough decoding to get the encoding
name to load a full charset.
On Aug 20, 2009, at 9:06 PM, shadow king wrote:
HI,
I am a chinese and I am using log4cxx as a logging facility in my
project(the locale in my linux server has been set to zh_CN.GBK).
when I switch to the 0.10.0 release(I used version 0.97 beta
before), I came cross a problem: all the chinese logging message
produced by my program could not be displayed correctly.
Therefore, I decided to examine the source, and i found something
which I suspect was the cause of my problem, the suspected code is:
std::string Transcoder::encodeCharsetName(const LogString val) {
char asciiTable[] = { ' ', '!', '', '#', '$', '%', '', '\'',
'(', ')', '*', '+', ',', '-', '.', '/',
'0', '1', '2', '3', '4', '5', '6' , '7',
'8', '9', ':', ';', '', '=', '', '?',
'@', 'A', 'B', 'C', 'D', 'E', 'F', 'G',
'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O',
'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', 'Z', '[', '\\', ']', '^', '_',
'`', 'a', 'b', 'c', 'd', 'e', 'f', 'g',
'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
'x', 'y', 'z', '{', '|', '}', '~', ' ' };
std::string out;
for(LogString::const_iterator iter = val.begin();
iter != val.end();
iter++) {
if (*iter = 0x30 *iter 0x7F) {
out.append(1, asciiTable[*iter - 0x30]); // this is the
problematic line of code for me.
} else {
out.append(1, LOSSCHAR);
}
}
printf(out.c_str());
return out;
}
I replace the line out.append(1, asciiTable[*iter - 0x30]); to
out.append(1, *iter);, then my problem was solved.(The input
arguement of this function is GBK in my system. Before I hacked
the code, this function resturn 12;; After the hacking, this
function return GBK which is my desire result).
I don't understand why we need to change the name of the charset
name(for the fear of non-ascii charset names? even with that fear,
I can't see the need of changing from GBK to 12;)
Re: efficiencies of getLogger()
The typical pattern is to use a static logger member in a class which
results in getLogger() being called once per class during
initialization:
foo.h
class Foo {
statlc log4cxx::LoggerPtr logger;
void hello();
};
foo.cpp
log4cxx::LoggerPtr Foo::logger(Logger::getLogger(foo));
void Foo::hello() {
LOG4CXX_INFO(logger, Hello);
}
Did you have a compelling reason to make repeated calls to getLogger()?
If your caching improved performance, there must be some potential for
optimization to getLogger() which should be doing roughly the same
thing internally. Frequent calls to getLogger() is an atypical usage
pattern, so it hasn't been benchmarked.
On Aug 18, 2009, at 3:19 PM, david.we...@l-3com.com wrote:
All,
I was recently working on a project which was very time sensitive.
Milliseconds were prescious, and we had great interest in using
LOG4CXX, only in debugging problems (where time wasn't nearly as
critical).
On the web site, I saw that getLogger(asdf) will return the same
object as a subsequent call to getLogger(asdf). When we created
multiple objects of the same type, each of which had a logger
instance with the same name, we profiled the code, and found that
eacy getLogger() call was taking quite a lot of time. Unfortunately
the numbers are lost, but it was something like 100 us or ms. These
numbers are a world apart, but when it came to creating ~1000 of my
own objects, the amount of time spent creating those loggers became
unacceptable.
We ultimately found that by creating a caching mechanism using a
loggerName - loggerObject map, made the subsequent calls much
more manageable.
I was just wondering if anyone else has seen this sort of behavior.
--dw
Re: Building with Visual 2005 fails
On Aug 12, 2009, at 1:28 AM, resul sahin wrote: Hello, When I build the log4cxx on Visual 2005 according to instructionshttp://logging.apache.org/log4cxx/building/vstudio.html , I am getting error below; 1-- Build started: Project: apr, Configuration: Debug Win32 -- 1Compiling... 1userinfo.c 1c:\program files\microsoft visual studio 8\vc\platformsdk\include \rpcndr.h(145) : error C2059: syntax error : ':' 1c:\program files\microsoft visual studio 8\vc\platformsdk\include \rpcndr.h(898) : error C2059: syntax error : ',' . . . 1c:\program files\microsoft visual studio 8\vc\platformsdk\include \rpcndr.h(3119) : fatal error C1003: error count exceeds 100; stopping compilation When clicking the first error moves to code below / * Other MIDL base types / predefined types: / typedef unsigned char byte; typedef ::byte cs_byte; // error indicates here Is there any comments? Thanks In Advance Resul Don't see how log4cxx is involved here. I'm thinking that the compiler is doing strict C compiling for that file with the .c extension and the header file includes a C++ construct (the leading :: to ensure that the global definition of byte is being used). You can likely change a compiler setting to do C++ compilation for all source files.
Re: logString issue...please help
On Aug 11, 2009, at 2:12 PM, ss ak wrote: string logfile = logfile1.log; printf(\n in main () ); log4cxx::FileAppenderPtr fileAppender = new log4cxx::FileAppender(log4cxx::LayoutPtr(new log4cxx ::SimpleLayout ()),log4cxx::helpers::Transcoder::decode(logfile.c_str()),false); log4cxx::helpers::Pool p; fileAppender-activateOptions(p); printf( \n second printf); log4cxx::BasicConfigurator::configure(); //configure(log4cxx::AppenderPtr(fileAppender)); log4cxx::LoggerPtr logger = log4cxx::Logger::getLogger(logger); logger-setLevel(log4cxx::Level::getAll()); logger-addAppender(fileAppender); LOG4CXX_INFO(logger,IN main method); Now the file is created but does not write anything into it or does not print second printf the program just aborts,after creating the file... please help..i need this to be done todaythanks You don't mention the platform, guessing Windows. There is the possibility of shutting down Apache Portable Runtime before shutting down log4cxx if the first thing you do is to create a Ptr without initializing it. I wanted to avoid the cost of checking for APR startup in every Ptr constructor, but it seems like this hits a lot of people. Probably should go ahead and change that and take any performance hit. The main thing is to do: FileAppenderPtr fileAppender(new FileAppender...) instead of FileAppenderPtr fileAppender = new Appender... The first constructs the FileAppender first then initializes the pointer. The other constructs the pointer first then the FileAppender. Since destruction happens in reverse order of construction, you want to construct the FileAppender first. -- Forwarded message -- From: ss ak ssa...@gmail.com Date: Tue, Aug 11, 2009 at 9:43 AM Subject: logString issue...please help To: log4cxx-user@logging.apache.org string logfile = logfile.log; log4cxx::helpers::Transcoder::decode(logfile.log,12,logstr); log4cxx::BasicConfigurator::configure(); log4cxx::FileAppenderPtr fileAppender(new log4cxx::FileAppender()); //log4cxx::Layout(new log4cxx::SimpleLayout(; fileAppender-setAppend(true); fileAppender-setFile(logfile.c_str()); logger-setLevel(log4cxx::Level::getAll()); logger-addAppender(fileAppender); I get this error...please help error C2664: 'void log4cxx::FileAppender::setFile(const log4cxx::LogString )' : cannot convert parameter 1 from 'const char *' to 'const log4cxx::LogString ' 1 Reason: cannot convert from 'const char *' to 'const log4cxx::LogString' 1 No constructor could take the source type, or constructor overload resolution was ambiguous 1 string logfile = logfile.log; log4cxx::helpers::Transcoder::decode(logfile.log,12,logstr); log4cxx::BasicConfigurator::configure(); log4cxx::FileAppenderPtr fileAppender(new log4cxx::FileAppender()); //log4cxx::Layout(new log4cxx::SimpleLayout(; fileAppender-setAppend(true); fileAppender-setFile(logfile.c_str()); logger-setLevel(log4cxx::Level::getAll()); logger-addAppender(fileAppender); If all you wanted to do is explicitly set the file name, you should have done: fileAppender-setFile(LOG4CXX_STR(logfile.log)); As long as the constant only contains ASCII characters it will use either the proper type of literal or do a transcoding.
Re: linking errors when trying to use log4cxx as a static library (VC2008)
On May 29, 2009, at 12:09 PM, Gerrit van Doorn wrote:
Hi,
I compiled log4cxx as a DLL before and it worked perfectly. Now I
wanted to use log4cxx (version 0.10.0) as a static library. I've set
the Configuration Type to Static Library .lib in the log4cxx
properties and I changed the Preprocessor - Preprocessor
definitions to LOG4CXX_STATIC. When I compile in release mode I get
a library file that is about 14MB big. When I try to use this
library in a simple program I get the following linker errors:
1Linking...
1main.obj : error LNK2001: unresolved external symbol
__declspec(dllimport) public: static class
log4cxx::helpers::ObjectPtrTclass log4cxx::Level __cdecl
log4cxx::Level::getWarn(void) (__imp_?getw...@level@log4cxx@@SA?AV?
$objectp...@vlevel@log4cxx@@@help...@2@XZ)
1main.obj : error LNK2001: unresolved external symbol
__declspec(dllimport) public: class std::basic_stringchar,struct
std::char_traitschar,class std::allocatorchar const
__thiscall log4cxx::helpers::MessageBuffer::str(class
log4cxx::helpers::CharMessageBuffer ) (__imp_?
s...@messagebuffer@help...@log4cxx@@qaeabv?$basic_str...@du?
$char_tra...@d@std@@v?$alloca...@d@2@@std@@aavcharmessagebuf...@23@@Z)
...
What am I doing wrong?
Here is the basic example:
#include log4cxx/logger.h
log4cxx::LoggerPtr logger(log4cxx::Logger::getLogger(myLogger));
void main(void) {
LOG4CXX_WARN(logger, Some warning);
}
- Gerrit
Notice that your link errors have __declspect(dllimport) which
indicates that your calling code is still expecting to link with a
log4cxx.dll. Likely, you did not define LOG4CXX_STATIC when you
compiled your application.
Re: Programmatic Configuration of XMLSocketAppender
Nothing I've seen in the log4cxx codebase suggests that XMLSocketAppender accepts a layout specification. The log4cxx 0.10.0 code uses an XMLLayout in its implementation, but it is private. My guess is that your attempt at specifying a layout is getting ignored. If you want to write your own SocketAppender that does not output XML, you can base it off of SocketAppenderSkeleton. On May 28, 2009, at 9:21 PM, Henry Chou wrote: Hello, I currently am sending a log string using the an XMLSocketAppender, and am doing so by using the following configuration. config.xml: == appender name=MyXmlAppenderFormated class=org.apache.log4j.net.XMLSocketAppender param name=Port value=/ param name=RemoteHost value=192.168.1.101/ param name=ReconnectionDelay value=3/ param name=LocationInfo value=true / layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%d [%p] - %m%n/ /layout /appender == I have done this: pXMLSocketAppender_ = new log4cxx::net::XMLSocketAppender(192.168.2.31, 2009); Is there a way to modify the pattern programmatically? I can set most of these settings by using XMLSocketAppender- setOption(ReconnectionDelay,3), but the ConversionPattern parameter just isn't done the same way. Thanks ahead of time, -hc.
Re: Receiving LoggingEvent From SocketAppender (log4cxx 0.10.0)
On May 28, 2009, at 12:57 PM, Henry Chou wrote: Hello, I have scoured through the mailing list archive and found nothing that suits my desired outcome. I want to be receiving a LoggingEvent from a server, then parsing the event (ie: reconstructing a pattern by calling the getTimeStamp(), getLevel(), and getMessage() functions (iee: %d [%p] - %m%n), or the \pattern\ LoggingEventPatternConverter.cpp). Can anyone provide some example code for this to happen? I realize that I can use XMLSocketAppender, coupled with an PatternLayout to send a simple text string through TCP to the server. However, I need to be parsing these LoggingEvents in such a way that different tasks are to be done; this would mean that I would then have to parse a string which would not be ideal. With a LoggingEvent received from the server, I would be able to reconstruct, or even send the LoggingEvent to another server if for different log levels when using \spi\TriggeringEventEvaluator.cpp. Ruud Bos has had a problem similar to my own, but was solved by switching versions to log4cxx 0.9.7. I do not want addition packages such as Chainsaw, or log4j. Once again, the question is simple: is there example code around for a server to receive LoggingEvents generated by SocketAppender? Just for clarification, is SocketAppender sending a LoggingEvent at all or some other type of structure? If so, how would the server handle that? Thanks ahead of time, -hc. SocketAppender is sending a serialized form of LoggingEvent that is designed to be compatible with code that receives LoggingEvents from log4j 1.2 (such as Chainsaw). log4cxx 0.9.7 used a serialized form that varied depending on character type, endianness and, I think, the size of pointers and ints. While it would be difficult to write in C++ a receiver that could handle messages from log4j since events could include any arbitrary Java class as message parameters, it would not be particularly difficult to handle messages if they were known to only come from log4cxx since that format is very deterministic. I would suggest too get started receiving events from XMLSocketAppender and see whether the XML parsing overhead is really significant for your application. If you find that it is, then you could modify the code to receive the serialized form output by SocketAppender.
Re: Caching LoggerPtr using local statics (the singleton pattern)
Try using the one parameter constructor for LoggerPtr, instead of the
default constructor and then an assignment:
static LoggerPtr
singleton(log4cxx::LogManager::getLogger(some.logger));
There is a slight difference in order of events between the two.
Using the default constructor, it is
1. Construct singleton
2. Call LogManager::getLogger()
2a. initialize APR, etc
3. Assign logger to singleton
With the one parameter it is
1 Call LogManager::getLogger()
1a initialize APR
3. Construct singleton
Since destruction events occur in reverse order, using the one-
parameter constructor results in APR being destroyed last.
On May 26, 2009, at 3:37 AM, Assaf Lavie wrote:
My program always crashes when I try to cache the LoggerPtr returned
from getLogger in a local static variable (i.e. singleton) like this:
LoggerPtr MyLogger()
{
static LoggerPtr singleton =
log4cxx::LogManager::getLogger(some.logger);
return singleton;
}
I assume this happens because of some APR related effect. Can
someone please shed light on this? Does this happen to you?
Re: Trivial.cpp example not working
It was a little unusual that you were going off such a old tag. The
current code is so unlike 0.9.7 which was the best release for a long
time but no longer can be supported.
You might try explicitly namesoace qualifying the classes like
::log4cxx::BasicConfigurator::configure
Otherwise try running the preprocessor to see what is getting expanded.
Can't help much over a holiday weekend.
On Apr 10, 2009, at 7:01 AM, Sylvester Steele
sylvesterste...@gmail.com wrote:
Hi,
I was trying out the the example at https://svn.apache.org/repos/asf/logging/log4cxx/tags/v0_9_6/examples/trivial.cpp
. Unfortunately it isn't working yet.
My code looks like:
#include iostream
#include log4cxx/logger.h
#include log4cxx/basicconfigurator.h
#include log4cxx/helpers/exception.h
#include log4cxx/ndc.h
using namespace std;
using namespace log4cxx;
using namespace log4cxx::helpers;
int main() {
BasicConfigurator::configure();
LoggerPtr rootLogger = Logger::getRootLogger();
return 0;
}
Thats it. No other conf files or anything.
The errors are:
1. BasicConfigurator has not been declared
2. configure was not declared in this scope
3. LoggerPtr was not declared in this scope
4. expected ; before rootLogger
I am using mingw with eclipse. I downloaded log4cxx, unzipped it.
Then I configured eclipse by going to: project properties -- C/C++
general -- Paths and Symbols --Includes tab -- select GNU C++ --
click add-- enter the log4cxx path. I can see the log4cxx files
under includes. If I control+click a log4cxx header that I
included, I can see the code as well.
What could I be doing wrong?
Thanks,
Sylvester
Re: Log file should exist? how to log Chinese characters?
On Apr 8, 2009, at 4:17 AM, Lijuan Zhu wrote: I am new to Log4cxx, and just got it into my projects. I have two questions now: 1, The log file I specified in the xml configuration file should exist? how to change the configuration so the log4cxx could create the log file if it does not exist? log4cxx should attempt to create the file specified if it does not exist, perhaps you are running your application with reduced privileges that prevent it from writing to the directory to create the file? 2. I could not log Chinese characters into the log file (there are something like this:2009-04-08 10:02:29,68? ERROR [ps.?f]??), is there any setting I can change to make it show the logs correctly? Thanks a lot, Lijuan Unless you specify otherwise, log4cxx will use the default encoding of your operating system if it can detect it. If you default encoding is something like ISO-8859-1 or USASCII, they are incapable of representing Asian characters. The easiest way would be to specify param name=encoding value=UTF-8/ or param name=encoding value=UTF-16/
Re: Log file should exist? how to log Chinese characters?
On Apr 8, 2009, at 4:17 AM, Lijuan Zhu wrote: I am new to Log4cxx, and just got it into my projects. I have two questions now: 1, The log file I specified in the xml configuration file should exist? how to change the configuration so the log4cxx could create the log file if it does not exist? 2. I could not log Chinese characters into the log file (there are something like this:2009-04-08 10:02:29,68? ERROR [ps.?f]??), is there any setting I can change to make it show the logs correctly? Thanks a lot, Lijuan Check the mailing list archive for more detail (search for locale and/ or encoding). You likely also need to make a call to setlocale, ideally called before your first log statement which will tell the run- time what encoding it should use to interpret char*. Without a call to setlocale(), the default is the USASCII.
Re: JMSAppender and Log4cxx
On Mar 30, 2009, at 7:11 PM, Greggg wrote: Hi All, I was wondering if there's a way to log (with Log4cxx) messages to JMS. I know that log4cxx doesn't have any JMSAppenders, something that Log4j comes with, but maybe there's a bridge or something that would let me do this. What I'm trying to do is have both Java and C++ clients send to the same JMS Broker (activeMQ) which delegates messages to a consumer - a JMSSink. (JMSSink is an app that also comes with Log4J .) Any ideas? Suggestions? Thanks Greg. I'd suggesting investigating http://activemq.apache.org/cms/.
Re: How to build simplesocketserver binary file?
On Mar 25, 2009, at 11:48 AM, Esther Parrilla-Endrino wrote: Hi Renny and all, I have followed your instructions and implemented a Java SimpleSocketServer application that is running with log4j, I have done a test Java class that initialize the logging and sends a couple of messages to the SimpleSocketServer and works fine, all messages sent by the test class are succesfully written in the same log file. There is a unit test for this in build.xml (see run-socketserver). Would be good if you check if that passes on your platform. Don't know of a reason why your test failed, but it isn't expected. Platform, Java version and the like is always helpful.
Re: How to build simplesocketserver binary file?
On Mar 24, 2009, at 10:19 AM, Moley Harey wrote: Hi, I have downloaded apache-log4cxx-0.10.0.tar.gz from Apacheś log4cxx web site and built the lib using the commands: configure, make, make install After that the lirbrary has been successfully built but the binary file simplesocketserver has not been generated :/ How can I get that? Thanks in advance, Mh In log4cxx 0.10, the binary format for the SocketAppender was changed to be compatible with log4j 1.2's, so that Chainsaw and any other application that could connect to log4j's SocketAppender. However, that support is write-only, it is fairly simple to write something that log4j can consume, but massively complicated to consume anything the log4j might produce. Since there log4cxx was compatible with log4j's binary format and log4j provides SocketReceivers, simplesocketserver was dropped. Also, The log4cxx 0.9.7 wire format was not platform independent, a x86_64 build could not connect to a x86 build or a little-endian to a big-endian.
Wedding plans
Sorry about being a little slow to respond recently, but I've been working on wedding plans. Julie Ferguson and I are marrying in New Braunfels, TX on December 27th. Julie and I have known each other a little over 6 years as friends and we kept in touch infrequently after she moved away from Houston. I dropped her my bi-annual how are you doing email a few months ago and it snowballed in to longer and longer emails, then phone calls and then face to face. Things have gone too well for it to be either of our doing. I do not expect to be checking the mailing lists frequently until January 4th or so. We would appreciate your prayers as we build our marriage. Our blog: http://curtandjulie.blogspot.com Registered at Amazon (http://tinyurl.com/curtjulie) and Sur La Table (http://giftreg.surlatable.com ).
Re: Modifying logFilePath for FileAppender using a PropertyConfigurator
On Dec 9, 2008, at 10:36 AM, [EMAIL PROTECTED] wrote:
So, I answered my own question by searching a bit more on google.
The syntax is ${ENVIRONMENT_VARIABLE}/directory/fileName.txt
Now, one more question:
How does one set up the logger to create a unique log file per run.
I'm
looking at dailyRollingFileAppender, 'cause I'm pretty sure something
does what I want.
Thanks
--dw
Look at log4cxx::rolling::RollingFileAppender. You could provide your
own triggering policy that rotates the files on first log statement or
you could override the class to rollOver() on startup.
Re: Link error when using Layout on MS Windows
On Dec 9, 2008, at 2:44 PM, peter.doornbosch wrote: Hi, log4cxx::LoggerPtr tmpLogger( log4cxx::Logger::getLogger(SIM.TEST) ); // set logger level tmpLogger-setLevel( log4cxx::Level::getDebug() ); // set appender properties === log4cxx::PatternLayoutPtr layout( new log4cxx::PatternLayout( %d %-5p [%l] [%c:%M] %m%n ) ); try this: new log4cxx::PatternLayout( L%d %-5p [%l] [%c:%M] %m%n ) (yes, that is an L before the quotes ;-) or switch your project to unicode. = i think the problem is that the pattern is interpreted as being of type char*, but the PatternLayout constructor expects unicode. hth peter Use LOG4CXX_STR() which takes an ASCII literal and prepends the appropriate qualifier (L or nothing) depending on configuration. log4cxx::PatternLayoutPtr layout( new log4cxx::PatternLayout(LOG4CXX_STR( %d %-5p [%l] [%c:%M] %m%n )) ); Anytime an argument takes a LogString or a logchar*, you should use LOG4CXX_STR() in the same manner you'd use _T() for TCHAR*.
Re: 2 AsynchAppender and a Deadlock
On Dec 2, 2008, at 8:08 AM, [EMAIL PROTECTED] wrote: Hi, I have tried to use two AsyncAppenders, which have some Appenders in common, in parallel. I ended up in a deadlock. Has this never been tested or is it the intention to use one AsyncAppender at a time only?? This is not an offense, just a question!! I can live with the only one AsyncAppender at a time version. Cheers Stefan Connecting the same appender to two different AsyncAppenders would be a more likely source of problems than having two AsyncAppenders. Without a stack trace and your configuration, it is difficult to determine the nature of the problem.
Re: how to fix the error of '' inputstreamreader.cpp:66: error: 'memmove' was not declared in this scope ''
On Nov 25, 2008, at 8:43 PM, link wrote: when i compile log4cxx i get the same error message : inputstreamreader.cpp:66: error: 'memmove' was not declared in this scope can you tell how to fix it? Try adding to inputstreamreader.cpp a #include string.h and see if that helps. If it doesn't, search your compiler headers to see where it defines memmove(). Please report the compiler and OS in use, since this does not occur with most compilers.
Re: WG: doc links broken?
On Nov 7, 2008, at 4:35 AM, Andreas Pfaffenbichler wrote: Sorry, dyslexic error of mine. I am new at ---log4cxx---, and I found all links to the manual pages broken. Regards Andreas Pfaffenbichler Are these links on http://logging.apache.org or are these links in off- line resources? Please give specifics, I did some random clicking on http://logging.apache.org/log4cxx and didn't encounter any broken links.
ApacheCon live video streaming available; keynotes and Apache 101 are free
Can't make ApacheCon this week in New Orleans? You can still watch all the keynotes, Apache 101 sessions, and system administration track in live video streams: http://streaming.linux-magazin.de/en/program_apacheconus08.htm?ann Keynotes and the Apache 101 lunchtime sessions are free; the full sysadmin track, including httpd performance, security, and server stack administration talks are available for a fee. Keynotes include: - David Recordon, Six Apart (Wednesday 09:30) Learning from Apache to create Open Specifications - Shahani Markus Weerawarana, Ph.D. (Thursday 11:30) Standing on the Shoulders of Giants - Sam Ramji, Microsoft (Friday 11:30) struct.new(future, :open, :microsoft) Reminder: New Orleans is CST or UTC/GMT -6 hours. Advance notice: ApacheCon EU 2009 returns to Amsterdam, 23-27 March. We had a great response to our CFP and look forward to announcing the schedule in the next month. Regards -- Lars Eilebrecht - V.P., Conference Planning [EMAIL PROTECTED] - http://www.us.apachecon.com
Re: Log4cpp's SyslogAppender problem
On Oct 1, 2008, at 3:53 PM, Jacob L. Anawalt wrote: On 2008-10-01 12:00, Hoang, Minh-Long (Mission Systems) wrote: I'm having problem with log4cpp's SyslogAppender. Are you using log4cpp or Apache log4cxx? If you are using log4cpp, you should go to their mailing list.
Re: log4cxx 0.10 - make fails on Solaris 10
On Sep 30, 2008, at 7:52 AM, Ambarish Mitra wrote: Hello all, I have download the source of log4cxx 0.10, and trying to build on Solaris 10 - Sparc 64 bit. I have done configure correctly, and the makefile was generated. Now when I do a make, it gives me this error, and I do not know why it looks for libdb-4.2. Is there any dependency? What are all the dependencies? grep: can't open /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.la Not directly, but APR-Util can be built with a dependency on BerkleyDB. How did you build apr-util? You could specify ./configure --without-berkley-db when building apr-util. Haven't tried it myself.
Re: Accessing a LoggingEvent's properties using a PatternLayout
On Sep 21, 2008, at 8:11 PM, Adam Woods wrote: Can anybody help me with this issue? Is this a feature which was missed or is planned for a later release? Your help is greatly appreciated. Cheers, Adam Woods -Original Message- From: Adam Woods [mailto:[EMAIL PROTECTED] Sent: Wednesday, 17 September 2008 10:18 AM To: log4cxx-user@logging.apache.org Subject: Accessing a LoggingEvent's properties using a PatternLayout Hello List, I am trying to make use of the LoggingEvent's properties map so that my logs contain extra data specific to an event. This is implemented in log4net, so I didn't think I would run into any problems. However, on further investigation, the documentation and the code both suggest that there is no way to actually access the LoggingEvent's properties using the PatternLayout's syntax. Are the LoggingEvent's properties intended for this kind of use, or am I going about this the wrong way? Cheers, Adam Woods The nomenclature gets a little muddied. In log4j 1.2, there were no properties just the NDC (nested diagnostic context) and MDC (mapped diagnostic context) which were a thread-local stack and map, respectively. In the log4j 1.3 development (since abandoned), the term MDC was changed to Properties in some places, but there was not a separation between the concepts . log4cxx inherited from log4j 1.3 but appears to have separated MDC from Properties, though there is no distinct API for injecting or using properties. It does appear that MDC works in the same manner as log4j 1.2, but properties appear to be a non-functioning stub. I'm not an log4net expert, but it didn't seem to have a distinct properties API vs an MDC API. It just seems that MDC values are stored in a member called Properties. What were you trying to do and what didn't appear to work in log4cxx that did work in log4net?
Re: [log4cxx-users] Singleton class causes segfault at termination
On Sep 20, 2008, at 8:03 AM, Stefan Borovac wrote:
Hi Oscar,
just a guess. You are using an auto_pointer. That's
not necessary as LoggerPtr is already a smart pointer.
I had similar problems in the past. I have also designed a singleton
which wrapps log4cxx and end up in massive termination problems.
Maybe it helps.
Cheers
Stefan
Oscar Pereira wrote:
Hello all,
I have developed a C++ class (a sort of singleton..) to allow the
same instance of the logger to be used in several places. The code
is shown at the end of the email message.
In main, I just do this:
int main()
{
LOG4CXX_WARN(CLogger::GetLoggerInstance(), hello);
return 0;
}
and the program segfaults. Running it inside gdb yields this
backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219492160 (LWP 18963)]
0xb7aa6cfa in apr_pool_destroy () from /usr/lib/libapr-1.so.0
(gdb) bt
#0 0xb7aa6cfa in apr_pool_destroy () from /usr/lib/libapr-1.so.0
#1 0xb7e5e4f5 in ~Pool (this=0x805f234) at pool.cpp:46
#2 0xb7de7504 in ~AppenderSkeleton (this=0x805f200,
__vtt_parm=0xb7f020e4) at ../../../src/main/include/log4cxx/
appenderskeleton.h:48
#3 0xb7e8540d in ~SyslogAppender (this=0x805f200) at
syslogappender.cpp:93
#4 0xb7e4c6f5 in log4cxx::helpers::ObjectImpl::releaseRef
(this=0x805f254) at objectimpl.cpp:46
#5 0xb7de0bc2 in log4cxx::AppenderSkeleton::releaseRef
(this=0x805f200) at appenderskeleton.cpp:68
#6 0xb7de002e in ~ObjectPtrT (this=0x805e810) at ../../../src/main/
include/log4cxx/helpers/objectptr.h:100
#7 0xb7de0377 in ~AppenderAttachableImpl (this=0x805f048) at /usr/
include/c++/4.1.3/bits/stl_construct.h:107
#8 0xb7e4c6f5 in log4cxx::helpers::ObjectImpl::releaseRef
(this=0x805f05c) at objectimpl.cpp:46
#9 0xb7ddef82 in
log4cxx::helpers::AppenderAttachableImpl::releaseRef
(this=0x805f048) at appenderattachableimpl.cpp:41
#10 0xb7e3ad93 in ~Logger (this=0x8057ab0) at ../../../src/main/
include/log4cxx/helpers/objectptr.h:100
#11 0xb7e4c6f5 in log4cxx::helpers::ObjectImpl::releaseRef
(this=0x8057ae8) at objectimpl.cpp:46
#12 0xb7e365d2 in log4cxx::Logger::releaseRef (this=0x8057ab0) at
logger.cpp:62
#13 0xb7de7d27 in ~ObjectPtrT (this=0x804b6f0) at ../../../src/main/
include/log4cxx/helpers/objectptr.h:100
#14 0x08049355 in ~auto_ptr (this=0x804ae90) at /usr/include/c++/
4.1.3/memory:259
#15 0x08049100 in __tcf_1 () at CLogger.cpp:15
#16 0xb7afd594 in exit () from /lib/tls/i686/cmov/libc.so.6
#17 0xb7ae6058 in __libc_start_main () from /lib/tls/i686/cmov/
libc.so.6
#18 0x08049071 in _start ()
(gdb)Can anyone make any sense of this? The
logmanager part is something that I tried to see if that kept the
program from segfaulting...
Thanks in advance,
Oscar
---Singleton Code---
//file CLogger.hh
#pragma once
#include log4cxx/logger.h
class CLogger
{
public:
static log4cxx::LoggerPtr GetLoggerInstance(void);
static void initializeMpsLogger(const char* configure_path);
~CLogger(void) { }
static void quit(void);
private:
static std::auto_ptrlog4cxx::LoggerPtr m_pLoggerInstance;
static const char* m_cConfigurationFile;
CLogger(void);
};
//CLogger.cpp
#include CLogger.hh
#include iostream /* for stderr */
#include log4cxx/propertyconfigurator.h
#include log4cxx/logmanager.h
using std::cerr;
using std::endl;
using log4cxx::LoggerPtr;
using log4cxx::Logger;
using log4cxx::PropertyConfigurator;
std::auto_ptrlog4cxx::LoggerPtr CLogger::m_pLoggerInstance;
const char* CLogger::m_cConfigurationFile=./log4cxx.config;
CLogger::CLogger(void){
}
LoggerPtr CLogger::GetLoggerInstance(void){
if (m_pLoggerInstance.get() == 0){
m_pLoggerInstance.reset(new LoggerPtr(Logger::getLogger(mps)));
try{
PropertyConfigurator::configure(m_cConfigurationFile);
}catch(std::exception e){
cerr Error while configuring logger using conf file
m_cConfigurationFile endl;
}
}
return *m_pLoggerInstance;
}
void CLogger::initializeMpsLogger(const char* configure_path)
{
m_cConfigurationFile = configure_path;
}
void CLogger::quit(void){
log4cxx::LogManager::shutdown();
}
The issue is that APR is getting terminated before the auto_ptr is
being released. I need to tweak the definition of ObjectPtrT so that
the default constructor forces APR initialization so that APR is
terminated after its destruction.
Adding any statement prior to the auto_ptr that initializes APR will
cause APR to be terminated after the destruction of auto_ptr:
+namespace {
+ LoggerPtr root(Logger::getRootLogger());
+}
std::auto_ptrlog4cxx::LoggerPtr CLogger::m_pLoggerInstance;
As previously noted, LoggerPtr itself is a smart pointer, so
wrapping it in std::auto_ptr is redundant.
It seems like a lot of effort to change the configuration file name
from log4cxx.properties to log4cxx.config. Multiple calls to
getLogger() with the same logger name return a smart pointer to the
same Logger instance so it is not necessary to try to
Re: Initialization problem
On Sep 17, 2008, at 5:35 AM, Alexander Rojas wrote: I'm working on Ubuntu 8.04 Hardy, log4cxx version 0.9.7-6, gcc 4.2.3. The IDE is kdevelop and the file is encoded as UTF-8. I don't know if this is all the relevant information. Thank you for your help Alexander Rojas log4cxx 0.9.7 is obsolete and no longer supported. log4cxx 0.10.0 is the current release.
Re: Forward Declaration
On Sep 12, 2008, at 12:00 PM, Jon Dahl wrote:
Hello,
I'm wondering if it is possible to use forward declaration with
log4cxx classes in a class header file. I would like to exclude the
log4cxx headers files in my header files if possible and include the
log4cxx header files in my cpp(source) files.
Should this work?
No. LoggerPtr is a template expansion and you'd need at least the
template definition incorporate it in a header file. However, you may
want to consider not having a LoggerPtr in your class definition at
all, but just have it in your implementation. Something like:
myfoo.cpp
#include log4cxx/logger.h
// anonymous namespace, members are visible only in this compilation
unit
// like static but better
//
namespace {
log4cxx::LoggerPtr logger(log4cxx::Logger::getRootLogger());
}
void Foo::someFunction() {
LOG4CXX_INFO(logger, Hello, World);
}
Re: Can't build using Ant with MSVC 6.0
On Aug 27, 2008, at 6:48 AM, Moshe Matitya wrote: I am trying to build log4cxx 0.10.0 using ant, but the build fails because of apr-util compilation errors. Am I doing something wrong here? I am using the following environment: Micosoft Windows XP SP2 Microsoft Visual C/C++ 6.0 SP 6 Microsoft Platform SDK Feb. 2003 Apache Ant 1.7.1 AntContrib 1.0b3 CppTasks 1.0b5 log4cxx 0.10.0 apr 1.3.3 apr-util 1.3.4 The APR and APR-Util versions listed are substantially later than the ones that were current at the time of the log4cxx 0.10.0 release. If I remember correctly, 1.2.12 was the current release, but compilation problems resulted in releasing against APR 1.2.11 and APR-Util 1.2.10. Does log4cxx build properly on your configuration with those versions of APR and APR-Util? If so, then we can look at figuring out what has changed and how to either compensate or push the issue back to APR.
Re: apr-util-expat
On Aug 13, 2008, at 9:19 AM, Mehta, Jenica wrote: 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 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: Upgrading from 0.9.7 to 0.10.0 - Pool Information
On Aug 1, 2008, at 4:39 PM, Chris D'Annunzio wrote:
Hello,
I am in the process of upgrading from version 0.9.7 to 0.10.0 of the
log4cxx library. I’ve successfully built the library and I am now in
the process of integrating into our product.
Some of the methods that we were previously calling have a new
required log4cxx::helpers::Pool parameter. For example, we are
calling the activateOptions() method on an log4cxx::AppenderPtr.
From what I can tell, this appears to be a memory pool interface
that log4cxx uses internally. What is the proper way to get this
Pool object? Am I supposed to create one myself during
initialization? I can’t seem to find any mention of it in the
documentation.
Any help would be greatly appreciated.
Best Regards,
Chris D’Annunzio
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::vectorAppenderPtr::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.
Re: Extending DailyRollingFileAppender
Log4cxx::rolling::RollingFileAppender is designed to use an arbitrary triggering policy. Drfa is just an instance precinfigured with a specific policy. Instead of writing a new appended, you should consider writing a custom triggering policy. On Jul 29, 2008, at 6:48 AM, Moshe Matitya [EMAIL PROTECTED] wrote: I am interested in extending DailyRollingFileAppender. The existing appender can be configured to roll over at intervals like once a month, once a week, once a day, once a half-day (AM/PM), once a minute, etc. What I need is to be able to roll over at other intervals in between, such as every ten minutes. Does anyone know of an already-written appender that supports this? Alternatively, where can I find documentation of what I need to do to write a new appender (for log4cxx of course, as opposed to log4j), and what I'd need to change from DailyRollingFileAppender to support the added functionality? Thanks, Moshe
Re: Build log4cxx as static library using MS Visual Studio 2003
On Jul 15, 2008, at 1:25 AM, Eberhard, Markus (external) wrote: Hello *, I ma trying to build log4cxx as static library using MS Visual Studio 2003, but it doesn’t work. I have opened the project log4cxx.dsw of the log4cxx package, converted it to a MS Visual Studio 2003 project, set the project “log4cxx” as start-up project and changed two properties: - build “static library” not “dynamic library” - and the pre-processor definition “LOG4CXX” to “LOG4CXX_STATIC” When linking during the build process I get 544 warnings like the followings: apr-1.lib(dir.obj) : warning LNK4006: [EMAIL PROTECTED] already defined in aprutil-1.lib(dir.obj); second definition ignored apr-1.lib(fileacc.obj) : warning LNK4006: [EMAIL PROTECTED] already defined in aprutil-1.lib(fileacc.obj); second definition ignored Linking my own test project with the build static library results in the following errors: log4cxx.lib(start.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function [EMAIL PROTECTED] log4cxx.lib(start.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function [EMAIL PROTECTED] log4cxx.lib(apr_snprintf.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _conv_in_addr log4cxx.lib(sockaddr.obj) : error LNK2001: unresolved external symbol [EMAIL PROTECTED] log4cxx.lib(sockaddr.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _apr_sockaddr_vars_set … What have I to do to get the static library running? Please help. Thanks Markus Add advapi32.lib, mswsock.lib, ws2_32.lib and shell32.lib to the libraries used in the link step. log4cxx.dll is dependent on those system libraries. When you link with the static library, you also have to include the libraries dependencies.
Re: MAKE error : While compiling trivial.cpp:Urgent
On Jul 3, 2008, at 1:27 AM, srkraju wrote: When I give the ./configure command in apache-0.10.0 directory. It is giving following error: configure: error: APR could not be located. Please use the --with-apr option. What may the problem? Is with-apr option is required or can we skip that from compiling. --with-apr and --with-apr-util are required if apr and apr-util are not in the expected location (typically /usr/lib). If you built and installed APR and APR-Util yourself, you may need to specify: ./configure --with-apr=/usr/local/lib --with-apr-util=/usr/local/lib
Re: MAKE error : While compiling trivial.cpp:Urgent
On Jul 2, 2008, at 11:02 PM, srkraju wrote: Dear curt, I tried to commented the calls and getting the following error while I try to compile on Redhat Linux AS4(g++3.4.3). Kindly assist me to solve this issue. thanks regards srkraju From my previous message: ~ ~I've set up a virtual machine running CentOS 4.0 x86 which comes with ~gcc 3.4.3 and did not have any issues. There have been no other ~reports of similar catastrophic failures to compile. It looks very ~much like a local machine issue and would be difficult for anyone to ~diagnose remotely. It almost appears that your header files are empty ~or that you've removed the include directives or using namespace ~directives from the source file. As far as I can tell, there is something specific to your machine that is causing the problem. If there is another developer who could take a look at the problem, he might track down the issue faster. If not, I would suggest the following: Download apache-log4cxx-0.10.0.tar.gz. The following assumes it was downloaded to ~/downloads: $ mkdir newdir $ cd newdir $ tar -xvzf ~/downloads/apache-log4cxx-0.10.0.tar.gz $ cd apache-log4cxx-0.10.0 $ ./configure $ make Based on your reports, you should have completed the previous commands without problems, Then try $ make check If that completes successfully, then you have successfully built trivial and you can run it using $ src/examples/cpp/trivial If the make succeeded, there is some local change to the original log4cxx source that is responsible for the compile failures. If make check failed with the previously reported compile failures, then try: $ rm src/examples/trivial.o $ rm src/examples/trivial $ make CXXFLAGS=-E check That should create a trivial.o which is the preprocessor output and not actually an object file. Rename and attempt to compile this file to see if you get the same errors: $ cd src/examples/cpp $ mv trivial.o test.cpp $ gcc -c test.cpp If that fails, compress test.cpp, create a new JIRA bug report (http://issues.apache.org/JIRA/browse/LOGCXX ) and attach test.cpp.gz. $ gzip test.cpp
Re: Unable to build Apr-util - missing rules.mk
On Jun 25, 2008, at 2:53 PM, David Tran wrote: Hi, I am not very familiar with APR and APR-utils. I ran configure, make, and make install on apr fine, but when I try to make/make install apr-utils, it can’t find the file build/rules.mk Specified in the generated Makefile. Can anyone tell me what I’m doing wrong or give a good pointer for a newbie? Thanks! Try specifying the location of APR on the apr-util configure, like: ./configure --with-apr=PATH If you did that and it still doesn't work, review the APR-util build instructions for anything that you missed and then try asking on [EMAIL PROTECTED] and provide much more detail on the system. [EMAIL PROTECTED] will have experience on a wider range of platforms than log4cxx-user@logging.apache.org and is the right venue for apr-util build problems.
Re: MAKE error : While compiling trivial.cpp:Urgent
On Jun 19, 2008, at 10:56 PM, srkraju wrote: Still I am unable to solve this make error. Please suggest any modifications required in trivial.cpp Can use the libraries(like log4cxx,apr-1.2.2, aprutil-1.2.2) which are built in g++4.x in 3.x . thanks regards srkraju I had no problems on CentOS 4.5 (gcc 3.4.6) which is my closest approximation to your environment. I am using apr 1.2.12 and apr- util-1.2.12, but that should have no impact on a compile error. Have you made any local modifications, particularly to log4cxx/helpers/ messagebuffer.h? That file had been a concern when you were attempting to build with gcc 2.96. As far as I can tell, gcc 3.4.3 was in the original RHEL 4 but was upgraded to gcc 3.4.4 in Update 2. If you are still seeing the issue, time for some experimentation. The error is indicating that log4cxx::helpers::MessageBuffer is not defined, this class is referenced by an expansion of the LOG4CXX_DEBUG and similar macros. Try the following experiments: 1. #if 0 out all the LOG4CXX_DEBUG and similar macros removing all the logging requests. Run make. Would expect no compile issues. 2. Add the following line to trivial.cpp at the same place as the #if 0'd logging requests ::log4cxx::helpers::MessageBuffer oss; Attempt to build. This should fail with the same type of warning. 3. Try removing the leading :: in the preceding line. If that compiles while the previous line fails, then remove the leading :: from the macro definitions in logger.h. If anyone has similar reports or wants to report no problems with gcc 3.4.3 please speak up. From what I can tell, it is either a compiler specific issue or a local modification.
Re: URGENT compliation error of sample program (test.cpp)
On Jun 14, 2008, at 8:24 AM, Dale King wrote: On Sat, Jun 14, 2008 at 2:51 AM, srkraju [EMAIL PROTECTED] wrote: Though its giving the same error. I downloaded Ant-1.6.5. and extracted into /home/facts/Test/apache-ant-1.6.5/ directory. g++ test.cpp -I/home/facts/Test/apache-log4cxx-0.10.0/src/main/ include -L/home/facts/Test/apache-ant-1.6.5/lib/ -L tells the linker where to look for libraries. You have to actually specify what libraries to look for as well using the -l option. So if your directory had libfoo.so in it that you needed to link with, you would add -l foo to your command line. Apache Ant is a build tool implemented in Java. You are placing the library directory of that product which contains only Java .jar files in the search path of a linker command that operates on .so, .a, .la or the like. That accomplishes nothing. log4cxx does provides for itself both autotools build script (the common approach for Unix environments) and an Ant based build script that is used for Unix and other platforms. However, what build script used to build your application is independent. What you likely should do is run: cd apache-log4cxx-0.10.0 make sudo make install which will build log4cxx and then install it to /usr/local/lib. Then you should be able to do: g++ test.cpp -llog4cxx (unlikely, but if it can't find log4cxx add a -L/usr/local/lib).
Re: URGENT compilation error of sample program
On Jun 14, 2008, at 6:58 AM, srkraju wrote: Thanks Mr. Dale. I solved the link error problem by location the shared objects generated by Log4Cxx_0.10.0, Apr_1.2.2, Apr-Util_1.2.2 packages. [ Redhat Enterprise Linux AS5, g++ version 4.1.1] I am trying to run the sample programs (bar.h, bar.cpp, MyApp2 given in the link http://logging.apache.org/log4cxx/index.html I am not getting the output exactly as expected. When I don't pass any argument it's giving [EMAIL PROTECTED] Examples_srk]$ ./MyApp2 0 [0xb7faaa20] INFO MyAppSrk null - Entering application. 0 [0xb7faaa20] DEBUG com.foo.bar null - Did it again! 0 [0xb7faaa20] INFO MyAppSrk null - Exiting application. When I pass one argument it's giving [EMAIL PROTECTED] Examples_srk]$ ./MyApp2 TestFile log4cxx: Could not read configuration file [TestFile]. log4cxx: No appender could be found for logger (MyAppSrk). log4cxx: Please initialize the log4cxx system properly I understand that the configuration file is not properly written. What is the format to write the configuration file? Can anybody give a template of configuration file? I also tried with the configuration file given in the above link. Still it is giving the same output. Is there a file named TestFile in your current working directory? log4cxx is reporting that you told it to read TestFile from the current working directory and use it as its configuration and the file could not be found. There is an example of what the contents of the configuration file could look like following the source of MyApp2.cpp in the tutorial. You should save that as TestFile and place that in the current directory.
Re: MESSAGEBUFFER.H COMPILATION PROBELM
On Jun 12, 2008, at 11:46 PM, srkraju wrote: I tried with make, make install. And then proceeded. Now, I have tested 'make check' option. It also giving the same errors in messagebuffer.h thanks regards srkraju gcc 2.96 was a prerelease version of gcc 3.x and has an incomplete implementation of the C++ Standard Template Library (see http://gcc.gnu.org/gcc-2.96.html) . I have been able to get messagebuffer.h to compile by forward declaring std::ios_base and replacing std::basic_ostreamchar with std::ostream and similar changes, but there are also compilation failures in cachedateformat.cpp and properties.h and there may be others. I do not intend to work around gcc 2.96's limitations.
Re: Unable to display caller name in log info
On Jun 13, 2008, at 10:15 AM, Debarshi Sanyal wrote:
Hi,
I wrote a small Java program to configure an org.apache.log4j.Logger
and log messages using it.
Excerpts from the Java file are:
package MyPackage;
//...
public class LogTest
{
private static Hashtable cLoggerHash = new Hashtable();
private void setLogInfo()
{
String sLogFile = TestLogFile.log;
Logger cLogger = Logger.getLogger( sLogFile );
cLogger.setLevel( Level.toLevel(DEBUG) );
PatternLayout cLayout = new PatternLayout();
cLayout.setConversionPattern( [%d{/MM/dd HH:mm:ss.SSS}]
%C - %m%n );
RollingFileAppender cFileAppender = new RollingFileAppender();
//...
cFileAppender.activateOptions(
);
cFileAppender.setLayout( cLayout );
cLogger.addAppender( cFileAppender );
cLoggerHash.put( sLogFile, cLogger );
}
public static void main (String[] args)
{
LogTest logTest = new LogTest();
logTest.setLogInfo();
Logger cLogger = Logger.getLogger( TestLogFile.log );
cLogger.log(TestLogFile.log, Level.INFO, \t +
+ This is a test log + , null);
}
The output is:
[2008/06/13 20:24:53.415]? - ++ This is a test
log +
The fully qualified classname is NOT displayed.
Instead a ? is displayed.
Please help.
Regards,
Debarshi
This question should have been asked on log4j-user, not log4cxx-user.
The most common cause is that the class file was not compiled with
debug information.
Re: How to set a FileAppender to STDOUT?
On Jun 11, 2008, at 1:34 PM, Peter Steele wrote: What do I need to specify in the File parameter to mean STDOUT? I have this: appender name=FILE class=org.apache.log4j.FileAppender param name=File value=System.out/ ... which works in log4j but this just creates a file called System.out in log4cxx. What's the magic formula? The log4cxx API comments are a copy from the log4j API comments, log4cxx probably never supported the special values. Don't know exactly when support was removed from log4j, but many years ago and maybe at the switch from log4j 1.1 to log4j 1.2. If it is really important to you, then you may need to write a custom appender.
Re: Segmentation fault log4cxx 0.10.0 on app exit (Solaris 8)
On Jun 9, 2008, at 8:05 PM, Allen Liu (allliu) wrote: Hi Curt, I compiled log4cxx-0.10.0 with gcc on 3 Solaris 8/sparc workstations, 2 of which were installed with apr/apr-util 1.2.12 whereas the other apr/apr-util1.2.7. Before applying the objectimpl.cpp workaround you provided, 1. 'make check' would fail on unit-test with exit status 139 2. a small test program I wrote got segmentation fault on exit After applying your workaround, 1. 'make check' passed on all 3 machine 2. my small test program still exited with 'segmentation fault' on the 2 machine installed with apr/apr-util 1.2.12. But it exited without a problem on the 3rd machine (with apr 1.2.7) Then I replaced apr/apr-util 1.2.12 with 1.2.7 on those 2 sun machines, 1. 'make check' passed 2. my small test program exited without 'segmentation fault' on all 3 machines I got the following question: 1. I got an impression from other posts that apr/apr-util 1.2.2 are officially used by log4cxx developers. Do I have to use 1.2.2? Or 1.2.7 should be fine? 2. Will there be a permanent fix to replace the workaround solution you provided in objectimpl.cpp? Thanks, Allen The reason for the premature termination of APR hasn't been identified: it may be a compiler bug or an log4cxx issue. The best workaround for now appears to be commenting out the apr_terminate() in src/main/cpp/aprinitialzer.cpp. However, removing the apr_terminate call would result in more reported memory leaking from tools like Valgrind. Until the nature of the underlying premature destruction of APRInitializer is known, their can't be a reasonable fix. It would be helpful to know the versions of gcc in use and whether the problems occur when using the most recent gcc release. Apache log4cxx 0.10.0 was built and tested against APR 1.2.11. There were some issues with APR 1.2.12 on VC6 without a Platform SDK update. The intent is that future releases will be built and tested using the current APR release. Nothing should prevent you from using log4cxx with earlier APR 1.x releases, but they aren't tested or supported.
Re: thread safe log4cxx
On Jun 8, 2008, at 1:43 PM, N N Murthy wrote: Our application is multi threaded application, developed using boost thread library. Is log4cxx thread safe? Where can we get more information? N N Murthy Logging should be thread-safe, all appenders and layouts that use shared resources should use mutexes to prevent simultaneous access to the resources. However, the standard disclaimers of warrantee or suitability for purpose apply here too. Can't promise that you can't get into trouble. If there are synchronization issues, they are more likely to occur when reconfiguring log4cxx during logging, so I'd recommend configuring log4cxx (either explicitly by a call to a configurator or implicitly by a making a logging request) before spinning up your threads.
Re: Using the syslog appender in log4cxx
On Jun 6, 2008, at 10:51 AM, Dale King wrote:
OK, I see now why it is only cosmetic. It only ends up being that way
because the strings differ only in a character that is not a letter.
That is a cumbersome way to do case insensitive comparison. It would
be a lot easier to lose the third parameter and do:
if (arg1.size() != arg2.size() ) return false;
for(int i = 0; i arg1.size(); i++) {
if (apr_toupper( arg1[i] ) != apr_toupper( arg2[i] ) ) return false;
}
(using apr_toupper for maximum portability). This could have problems
if you were trying to compare against accented or foreign characters,
but I think you are only comparing against ASCII.
That approach could have problems with the letter i due to the
Turkish i problem (http://en.wikipedia.org/wiki/Turkish_dotted_and_dotless_I
) which did affect log4j (https://issues.apache.org/bugzilla/show_bug.cgi?id=40937
). It seemed easier to just avoid the whole locale sensitivity of
case changing strings that contain i using the RTL and just hard
code the expected uppercase and lowercase versions.
Re: Is it safe to has different processes on the same machine log to the same file?
On Jun 5, 2008, at 1:23 PM, Stephen Bartnikowski wrote: I've been doing that for two years with no issue. It was my understanding that this was one of the major features of log4cxx, but I could be taking that for granted. - Stephen From: Peter Steele [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2008 1:18 PM To: log4cxx-user@logging.apache.org Subject: Is it safe to has different processes on the same machine log to the same file? This is what we’re doing right now and it appears to be working fine. Is this safe to do though, as a general rule? Depends on the file IO library under log4cxx for FileAppenders. RollingFileAppenders are likely very poorly behaved. The file size is determined from the initialize size and the number of bytes written by the appender, so file will likely be larger than the specified value when rolled. When they are rolled, either renaming may fail (usually on Windows) or one instance of rename the previous file and start a new one which other instances continue to write to the old, now renamed, file. When the other instances attempt to roll, bad things are likely to happen. log4cxx mimics log4j and there is no mechanism in Java to coordinate access to a shared file between multiple instances. The standard answer to that question for log4j is that database or network appenders should be used in that scenario.
Re: using RollingFileAppender
On Jun 2, 2008, at 7:13 AM, Madhu Gowda wrote: Hi all, I am trying to make use of RollingFileAppender. My code is as follows: LoggerPtr logger( Logger::getLogger(CustomLogger)); RollingFileAppender *pAppender = new RollingFileAppender(); Instead use: RollingFileAppenderPtr pAppender(new RollingFileAppender()); Otherwise, reference counts are likely to be mismanaged. pAppender- setName( log4cxx::helpers::Transcoder::decode(TestAppender)); pAppender- setFile( log4cxx::helpers::Transcoder::decode(TestLogFile.txt)); pAppender-setAppend( true); pAppender-setMaxBackupIndex( 5); pAppender-setMaxFileSize( log4cxx::helpers::Transcoder::decode(5 KB)); pAppender-setLayout( new PatternLayout( log4cxx::helpers::Transcoder::decode(%d [%t] %-5p %c - %l - %m%n))); If an appender (also applies to layouts, etc) is created with the default constructor, the activateOptions() method must be called after the properties are set. Pool p; pAppender-activateOptions(p); logger-addAppender( fAppender); This code is giving the error as: No output stream or file set for the appender named TestAppender But, if I create the appender as: RollingFileAppender *pAppender = new RollingFileAppender( new PatternLayout( log4cxx::helpers::Transcoder::decode(%d %-5p %c - %l - %m%n)), log4cxx::helpers::Transcoder::decode(TestLogFile.txt)); and I set the MaxBackupIndex and MaxFileSize as follows: pAppender-setMaxBackupIndex( 5); pAppender-setMaxFileSize( log4cxx::helpers::Transcoder::decode(5 KB)); It works fine but, the new log file is not getting created after the MaxFileSize (5 KB) is reached, the log messages are just getting appended to same log file (). When an constructor takes arguments, it has a call to activateOptions() to make it ready for action upon construction. However, any changes that occur after that point would need an call to activateOptions() to ensure that the changes are reflected in the behavior. Please, suggest what is going wrong here. Thanks Regards, Madhu Gowda
Re: Segmentation fault log4cxx 0.10.0 on app exit ( RH Linux)
On May 30, 2008, at 3:16 PM, GregN wrote:
Unfortunately your suggestion didn't fix the issue.
Under debugger the problem happen in apr_atomic.c::apr_atomic_dec32()
line:310.
It is inside #if APR_HAS_THREADS.
I tried to set APR_HAS_THREADS to 0 in include/apr.h but got system
lookup
error.
APR_HAS_THREADS ==1 is right and expected, the question is why:
#if (defined(__i386__) || defined(__x86_64__)) defined(__GNUC__)
!defined(USE_GENERAL_ATOMICS)
is not true.
Forget what I was saying about LoggerPtr. Looking at the stack trace
again that isn't the issue. The call to apr_atomic_dec32 that is
crashing isn't in the base class for LoggerPtr, it is in the base
class (ObjectImpl) for some log4cxx object that is defined as a
static. Just not clear which one.
A workaround until we can figure out the issue would be to change
objectimpl.cpp to avoid apr_atomic_inc32 and apr_atomic_dec32:
Index: src/main/cpp/objectimpl.cpp
===
--- src/main/cpp/objectimpl.cpp (revision 654826)
+++ src/main/cpp/objectimpl.cpp (working copy)
@@ -36,12 +36,12 @@
void ObjectImpl::addRef() const
{
- apr_atomic_inc32( ref );
+ ref++;
}
void ObjectImpl::releaseRef() const
{
- if ( apr_atomic_dec32( ref ) == 0 )
+ if ( --ref == 0 )
{
delete this;
}
Re: Server side socket usage
On May 20, 2008, at 8:26 AM, Ruud Bos wrote: Hi, The above example works like a charm, thanks a lot! Does anyone know why this has been removed from log4cxx 0.10.0 ? Ruud The classes that emulate Java library classes are only there to support log4cxx. They are not intended to be used a general purpose portable runtime, that is the role for Apache Portable Runtime (APR). If you do use them as a general purpose runtime, you need to be aware that any issues outside of their use by log4cxx will likely not be addressed or supported and that the needs of log4cxx may result in their changing in ways that may affect your use. SocketNode was removed since no log4cxx code used it. As such, having it there was just a temptation for someone to use it when they should be using APR.
Re: Server side socket usage
On May 15, 2008, at 9:45 AM, Ruud Bos wrote: Hello, I'm new to the list, so I have no idea if this question has been asked many times before. I hope someone can put me in the right direction. I'd like to use log4cxx for two applications. One acts as a client that needs to send it's logging to a server application using socket communication. Both programs are written in C++. From the few things I could find on the internet about the use of the ServerSocket class, I was not able to create something that works. Most of these only talk about the client side and use the java substitute log4j for the server side. If someone could point me to some example code, that would be extremely helpful. Thanks in advance, Ruud log4cxx 0.9.7 came with an implementation of both the client and server side for SocketAppender, but used its own format that was not platform independent. So if the sender and receiver differed in endianness, character type, int length or the like, bad things would happen. log4cxx 0.10.0 replaced that with an implementation that produced a stream format compatible with log4j's format (the Java serialization of its LoggingEvent class). This allows interoperability with Chainsaw and eliminated the platform variation of the format. There is a huge degree of variability allowed with Java serialization so it is much easier to write a logging event that can be read by Java serialization than reliably read a logging event written by Java serialization. You could write code that read log4cxx's specific take on it, but that would be unlikely to reliably read events from log4j. If you were going to receive events from log4cxx, I would suggest using the XMLSocketAppender as the format would require less custom code to parse the stream format. I'm sorry, but I'm not aware of any sample code for it.
Re: build head revision failed on windows xp
On May 14, 2008, at 1:20 AM, think twice wrote: i checkout the head revision of apr, apr-util , log4cxx, put them in the same root directory. Then i followed the instructions how to build log4cxx using ant on apache offical site, but it emits errors: [cc] D:\WorkSpace\apache-log4cxx\log4cxx\src\main\include\log4cxx/pattern/ lineseparatorpatternconverter.h(57) : error C2603: illegal access declaration: 'log4cxx::pattern::PatternConverter' is not a direct base of 'log4cxx::pattern::LineSeparatorPatternConverter' [cc] D:\WorkSpace\apache-log4cxx\log4cxx\src\main\include\log4cxx/pattern/ patternconverter.h(48) : see declaration of 'PatternConverter' -- View this message in context: http://www.nabble.com/build-head-revision-failed-on-windows-xp-tp17224117p17224117.html Sent from the Log4cxx - Users mailing list archive at Nabble.com. That is apparently due to the fix for LOGCXX-281 (rev 654700) which resulted in compiler warnings on the Sun Studio 11 compiler. Guess I'm going to need to iterate between Sun Studio and VC to figure out how to write the code to eliminate the Sun Studio warning and also compile under VC. I assume that you are using Visual C++, could you specify what version you are using? Until then, you could either check out the immediately preceding revision: svn update -r 654699 or remove the offending using namespace statements.
Re: LogString conversion
On May 12, 2008, at 9:15 AM, Madhu Gowda wrote:
Hi,
I tried the following in my sample program.
std::string sLogFile = TestLog.txt;
LogString sFileName;
log4cxx::helpers::Transcoder::decode( sLogFile, sFileName);
But, it gives the sFileName as .
I tried to debug and saw that in the function
void Transcoder::decode(const std::string src, LogString dst) {
the value of src is coming as Bad Ptr
Kindly advise on this.
Regards,
Madhu Gowda
The transcoding code is the most sensitive to platform differences.
The code path for transcoding on WIndows is very different from on
Linux, for example. To really be able to track down anything related
to transcoding, it is essential to know the platform, compiler and
build options.
Also, you are reporting something regarding a particular debugger's
display rendering of a particular STL libraries std::string class.
None of that is specific to log4cxx and is very specific to the
debugger and STL library in use. It may be that src is perfectly
usable, just that it is not being displayed the way you'd like.
Did you run the unit test suite? TimeBasedRollingTest fails
occasionally, but all the other tests should pass. If there is a
problem with encoding and decoding on your platform, it would likely
come up in the unit tests and it would be a lot easier to diagnose and
fix.
However, since you don't have any non-ASCII characters in your source
string, decoding should be as simple as copying character by character
into the destination. What happens when you single step through the
code?
Re: log4cxx 0.10.0 build problem on AIX
On May 12, 2008, at 2:43 AM, Chakravarthula, Krishnamurthy wrote: Experts, Since I am getting error with gcc compiler, I am trying with default compiler (/usr/vac/bin/xlc_r) on AIX for build. I am able to build APR and APR-UTIL but I get following error during make of log4cxx. Please help. source='helpers/datetimedateformattestcase.cpp' object='datetimedateform attestcase.o' libtool=no DEPDIR=.deps depmode=aix /bin/sh ../../../ depcomp xlC _r -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_S TRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\log4cxx\ -DVERSION= \0.10.0\ - DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 - DHAVE_STDLIB_H=1 -DHAV E_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 - DHAVE_INTTYPES_H=1 -DHAVE_STD INT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I../../../src/ main/include -I../../../src/main/include -U__STR__ -D_THREAD_SAFE -D_USE_IRS - D_LARGEFILE64_ SOURCE -I/tmp/apr/include -I/tmp/apr-util/include -I/tmp/apr-util/ xml/expat/l ib -g -c -o datetimedateformattestcase.o `test -f 'helpers/ datetimedateformatte stcase.cpp' || echo './'`helpers/datetimedateformattestcase.cpp helpers/datetimedateformattestcase.cpp, line 186.14: 1540-0218 (S) The call do es not match any parameter list for put. /usr/vacpp/include/xloctime.t, line 159.5: 1540-1283 (I) std::time_putchar,s td::ostreambuf_iteratorchar,std::char_traitschar ::put(ostreambuf_iterator char,std::char_traitschar , ios_base , char, const tm *, const char *, cons t char *) const is not a viable candidate. helpers/datetimedateformattestcase.cpp, line 186.35: 1540-0256 (I) A parameter of type char cannot be initialized with an expression of type const tm *. /usr/vacpp/include/xloctime, line 178.13: 1540-1283 (I) std::time_putchar,st d::ostreambuf_iteratorchar,std::char_traitschar ::put(std::ostreambuf_iter atorchar,std::char_traitschar , ios_base , char, const tm *, char, char) co nst is not a viable candidate. helpers/datetimedateformattestcase.cpp, line 186.35: 1540-0256 (I) A parameter of type char cannot be initialized with an expression of type const tm *. make: 1254-004 The error code from the last command is 1. Microsoft Visual C++ 6.0 shipped with an non-standard implementation of std::time_putT and std::use_facet. In the log4cxx implementation this is not currently checked by #if defined(_MSC_VER) _MSC_VER 1300 However in the unit tests, this was checked by #if defined(_USELOC) which is macro defined by VC6 to be used instead std::use_facet. It appears that _USELOC is defined in your build which cause the VC6 specific code path to be used instead of the C++ standard code path to be used and the calling parameters don't match since VC6 left out the fill character. Try the following change and see if that addresses the issue. Index: src/test/cpp/helpers/datetimedateformattestcase.cpp === --- src/test/cpp/helpers/datetimedateformattestcase.cpp (revision 654826) +++ src/test/cpp/helpers/datetimedateformattestcase.cpp (working copy) @@ -181,7 +181,7 @@ // output the using STL // std::basic_ostringstreamlogchar buffer; -#if defined(_USEFAC) +#if defined(_MSC_VER) _MSC_VER 1300 _USEFAC(locale, std::time_putlogchar) .put(buffer, buffer, date, fmt.c_str(), fmt.c_str() + fmt.length()); #else
Re: Individual logging output of multiple objects to multiple files
On May 8, 2008, at 7:12 AM, Michael Duerr wrote:
Hallo,
I'm writing a simulation application, that creates and destroys
several objects
of the same class during the simulation. I want to perform logging
for each of
these objects to a single file (i.e. I want only the output of one
object in the
corresponding object's logging file). The application is single
threaded.
Can I achieve this behaviour with log4cxx - if so - how? I tried to
implement
this behaviour by initializing a new logger for each new object. But
since there
are up to 1 objects this seems to be inefficient. Furthermore I
could not
figure out how to delete such a logger in case the associated object
gets
destroyed (how todo this???) and hence I experienced a lot of memory
leaks. To
my best knowledge MDC is also no alternative, since it does not
allow for the
restricted object-file logging.
Is there any chance to achieve this logging behaviour with log4cxx?
Thank you!
Cheers Michael
I agree with Dale's comments, but want to add some more.
The motivation of having a logger hierarchy is so to allow the user to
control the processing of logging requests by discarding some requests
and selectively routing others to specific appenders. Having 1
loggers with dynamic names has little value to someone who is trying
to shape logging in the configuration file.
If you really wanted 1 output files, the best approach would be to
use something like the mythical MultiFileAppender that lies unfinished
in the log4j sandbox. One appender, but can manage multiple open
files. Search log4j-dev for MultiFileAppender for the back story if
you are interested.
However, I agree with Dale that you'd be better off writing to a
single file and then appropriately sorting or filtering.
If you were using the mythical MFA, you'd need to have something in
the logging event to determine what file the event should be routed,
some sort of identification of the object. In the single file
approach, you could write this identifier out into the log file and
then use grep to pull out only the relevant log entries.
The question is then how do you get this object identifier into the
logging event. Your options are:
1. Put the object identifier into the message. Either something like:
LOG4CXX_INFO(logger, this Hello, World);
You'd need to provide an insertion operator for your object that works
on a log4cxx::helpers::MessageBuffer to insert the id. If advantage
of this is that it costs nothing if logging is disabled.
A cleaner solution would be to define your own macro that handled
inserting the object ID into the message.
2. Put the object identifier in the NDC on public method entry:
void foo() {
NDC entry(getID());
}
This will add an entry to the nested diagnostic context on method
entry and remove it on method exit. However, this adds a fixed cost
to the method call even if logging is disabled.
3. Put the object identifier in the MDC on public method entry:
void foo() {
MDC entry(objID, getID());
Same disadvantage and likely slower.
Re: Individual logging output of multiple objects to multiple files
On May 8, 2008, at 12:22 PM, Michael Dürr wrote: Hi Dale and Arnold, thanks a lot for your support. The idea to log from the beginning into different files was motivated by the size a single log file would have (up to 8GB) after a single run). But actually I have not thought at all about post processing the data which probably could take quite long. I'll give it a try. Thanks also for the advice to use the MultiFileAppender. I'll definitely have a look at it! Cheers, Michael MultiFileAppender is not a viable choice at the moment since it is just a skeleton implementation in the log4j sandbox. Let alone something that has been tested in log4j and ported to log4cxx. However, it is the right design for an appender that needs to write to distinct files per thread or some other criteria. The reason I brought it into the conversation was the need for you to get that criteria (in this case an object ID) into the logging event which would be needed regardless of whether you were using an MFA or a FileAppender with post-processing. If file size is your problem, then you could use a RollingFileAppender with a sized based triggering policy. Logging 8 GB per run seems like you are collecting more information that you could practically analyze.
Re: log4cxx 0.10.0 build problem on AIX
On May 7, 2008, at 6:34 AM, Chakravarthula, Krishnamurthy wrote: Experts, I want to build log4cxx on AIX. As part of that, I am building apr- util. I am getting following error when I do make of apr-util on AIX machine. I am using apr-util 1.2.12. My machine configurations are as follows. Please advice. Looks similar to https://issues.apache.org/bugzilla/show_bug.cgi?id=41550 If you have any failure with building APR or APR-Util, particularly on less common platforms, you'd be better off asking on [EMAIL PROTECTED] after doing a preliminary search. http://www.perzl.org/aix/index.php?n=Main.HomePage has packaged apr- util for AIX (don't have any experience with it, just the result of a search for AIX and apr-util).
Re: Urgent: log4cxx 0.10.0 build on HP Unix build problem
On May 3, 2008, at 6:04 AM, Chakravarthula, Krishnamurthy wrote: Hi Arnold, Please ask questions of the list instead of an individual developer. If you ask questions of a specific developer, that might discourage someone else from answering. I am getting following error when I do make of log4cxx. The earlier problems got resolved. They were because of my library path settings. Please advice. libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: `trivial' will be relinked during installation g++ -g -O2 -o .libs/trivial trivial.o -L/u/chakrava/apr -L/u/chakrava/apr-util -lm ../../../src/main/cpp/.libs/liblog4cxx.sl /u/chakrava/apr-util/.libs/libapru til-1.sl /u/chakrava/apr-util/xml/expat/lib/.libs/libexpat.sl /u/chakrava/apr/.l ibs/libapr-1.sl -lrt -lpthread /opt/hp-gcc64-4.2.1/lib/libstdc++.sl -L/tmp/gcc-4 .2.1.tar.gz/obj/hppa64-hp-hpux11.11/libstdc++-v3/src -L/tmp/gcc-4.2.1.tar.gz/obj /hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/tmp/gcc-4.2.1.tar.gz/obj/./gcc -L /opt/hp-gcc64-4.2.1/hppa64-hp-hpux11.11/bin -L/opt/hp-gcc64-4.2.1/lib -Wl,+b -Wl ,/u/chakrava/log4cxx/src/main/cpp/.libs:/u/chakrava/apr-util/.libs:/ u/ch akrava/a pr-util/xml/expat/lib/.libs:/u/chakrava/apr/.libs:/opt/hp- gcc64-4.2.1/li b:/usr/l ocal/lib:/usr/local/apr/lib ld: Can't find dependent library libaprutil-1.sl.2 Fatal error. collect2: ld returned 1 exit status *** Error exit code 1 Stop. *** Error exit code 1 Stop. *** Error exit code 1 Stop. *** Error exit code 1 Stop. Regards, Krishna I created a bug report for this at http://issues.apache.org/jira/browse/LOGCXX-280 . The fix is in the SVN HEAD, but I've provided the diffs below in case you want to fix up your existing build. HP-UX apparently has issues with linking to an uninstalled shared library which prevents the sample and unit test programs from linking. libtool indicates in your log file. I've modified src/test/cpp/Makefile.am and src/examples/cpp/ Makefile.am so that the example and unit test files are not compiled and linked during the default build target, but only when you do a make check. To run make check on HP-UX, you will need to first do a make install. = = = = = = --- logging/log4cxx/trunk/src/examples/cpp/Makefile.am (original) +++ logging/log4cxx/trunk/src/examples/cpp/Makefile.am Tue May 6 22:03:40 2008 @@ -13,7 +13,7 @@ # See the License for the specific language governing permissions and # limitations under the License. # -noinst_PROGRAMS = trivial delayedloop stream console +check_PROGRAMS = trivial delayedloop stream console INCLUDES = -I$(top_srcdir)/src/main/include -I$(top_builddir)/src/main/ include Modified: logging/log4cxx/trunk/src/test/cpp/Makefile.am URL: http://svn.apache.org/viewvc/logging/log4cxx/trunk/src/test/cpp/Makefile.am?rev=653989r1=653988r2=653989view=diff = = = = = = --- logging/log4cxx/trunk/src/test/cpp/Makefile.am (original) +++ logging/log4cxx/trunk/src/test/cpp/Makefile.am Tue May 6 22:03:40 2008 @@ -24,7 +24,7 @@ INCLUDES = -I$(top_srcdir)/src/main/include -I$(top_builddir)/src/main/ include -noinst_PROGRAMS = testsuite +check_PROGRAMS = testsuite customlogger_tests = \ customlogger/xlogger.cpp\
Re: Why are there unimplemented filters defined?
On May 1, 2008, at 9:45 AM, Dale King wrote: It looks like there are a few filters that have header files, but no source files. In particular, AndFilter, ExpressionFilter, LocationInfoFilter, MapFilter and PropertyFilter appear to not be implemented. If there is no implementation I don't think the headers should be included as this will confuse someone that sees them in the documentation and tries to use them. -- Dale King I've added LOGCXX-276 for this issue. The definitions were apparently added while porting over the log4j 1.3 rolling file appender, but the implementations were not exercised by the unit tests and the lack of implementation was not noticed. Removing the headers could cause a program that successfully compiled to fail to compile. Would have been okay to pull them before the 0.10.0 release, but now we need to keep compatibility until we are ready to jump to 0.11.x. The best way to fix the problem is to add the implementation in or if that is not possible to note in the headers that they are unimplemented.
Re: problems in building log4cxx-0.10.0
On Apr 30, 2008, at 7:41 AM, Madhu Gowda wrote: Hi, I am new to log4cxx. I downloaded the apache-log4cxx-0.10.0.zip, apr-util-1.2.10-win32- src.zip and apr-1.2.11-win32-src.zip. I am using Visual Studio 6.0 I am following the given instructions to build: unzip apr-1.2.11-win32-src.zip rename apr-1.2.11 apr unzip apr-util-1.2.10-win32-src.zip rename apr-util-1.2.10 apr-util cd apache-log4cxx-0.10.0 configure configure-aprutil (from http://logging.apache.org/log4cxx/building/vstudio.html) I get the apr-1.lib, libapr-1.dll and aprutil-1.lib built successfully but, when i try to build libaprutil-1.dll I am getting linker errors as: apr_dbd.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_brigade.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_buckets_alloc.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_buckets_mmap.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_buckets_pool.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_xml.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_dbd.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_queue.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_reslist.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] sdbm.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_brigade.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_buckets_alloc.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_buckets_mmap.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr_buckets_pool.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] . . . etc Please, give some suggestions on how to fix this. Regards, Madhu Gowda Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. The most common way to use log4cxx on Windows is to build log4cxx.dll against APR and APR-Util static libraries. You appear to have been able to successfully build APR and APR-Util as static libraries and could proceed to build log4cxx against them. However, I'll look into why you might be failing to build APR-Util as a dynamic library, though any problem would likely be an APR problem and not a log4cxx problem.
Re: problems in building log4cxx-0.10.0
On Apr 30, 2008, at 7:53 AM, Madhu Gowda wrote: Hi, I am new to log4cxx. I downloaded the log4cxx-0.9.7.tar.gz and built it on Visual Studio 2005. I am trying a sample program given in the document that reads the configuration from log4j.properties and logs the messages in given log file. my code is as follows: PropertyConfigurator::configure(_T(log4j.properties)); LoggerPtr rootLogger = Logger::getRootLogger(); rootLogger-debug(this is a DEBUG test message); rootLogger-info(this is a INFO test message); rootLogger-warn(this is a WARNING test message); The log messages in log file are printed as junk values as: 2008-04-30 18:20:54,060 [5240] DEBUG root - -/0@ )0@ Á«€|ÖQ@ 2008-04-30 18:20:54,060 [5240] INFO root - -/0@ )0@ Á«€|ÖQ@ 2008-04-30 18:20:54,060 [5240] WARN root - -/0@ )0@ Á«€|ÖQ@ I think the problem is in conversion to log4cxx::string. In my application I want to use std::string as the log messages How do I convert std::string to log4cxx string.. Please, give some suggestions on how to fix this. Regards, Madhu Gowda Use of log4cxx 0.9.7 is strongly discouraged, especially for new code. Please use log4cxx 0.10.0, we will get you through your build issues.
Re: Rolling File appender with compression doesn't seem to work
On Apr 29, 2008, at 11:38 AM, Dale King wrote:
I was testing out rolling file appenders (in Windows) which I set to
rollover every minute so I can see what happens. Here is the appender:
appender name=xmlfile
class=org.apache.log4j.rolling.RollingFileAppender
param name=filename value=log\log-current.xml/
rollingPolicy
class=org.apache.log4j.rolling.TimeBasedRollingPolicy
param name=FileNamePattern value=log\log
%d{HH_mm}.xml.zip/
/rollingPolicy
layout class=org.apache.log4j.XMLLayout
param name=properties value=true/
param name=locationinfo value=true/
/layout
/appender
It works fine if the .zip is not on there. With the .zip on there at
the top of the minute the file gets renamed to something like
log12_30.xml (no zip extenstion) and no new file is created so there
are no more logging events to the file system. I tried it without
using a directory in the name and it still did it.
--
Dale King
Do you have a zip.exe on the path? Compression relies on either a
gzip (if the extension is .gz) or zip executable to be on the path.
There is a zip utility in the Win32 API in the shell.lib if I recall,
but log4cxx does not attempt to use that.
The behavior when zip or gzip is missing likely could be improved.
Re: Core dump in Solaris - log4cxx 0.10.0 Sample Program.
On Apr 29, 2008, at 2:10 PM, Unnikrishnan Udinoor wrote: Hi, Need your valuable inputs/findings on this issue. Let me know if I am missing something here in the procedure. This is stopping us from upgrading of the log4cxx libraries to the latest version in our application. Problem Highlight: 1.The sample program for log4cxx 0.10.0 core dump if I compile for Solaris sparc and run. 2.Work around is defining the variable locally – i.e. by moving the variable (logger) declaration inside the main(). 3.The same program runs fine with Red hat 5. 4.The same program runs fine if I use log4cxx-r603007 version in both Solaris and Red Hat. ObjectImpl::releaseRef uses apr_atomic_dec32 to decrement the reference count when a pointer to the object is destructed. One most (but not all platforms and apparently not Solaris prior to Solaris 10), apr_atomic_dec32 simply delegates to a platform method or inline assembler. On platforms without a native atomic decrement, APR implements apr_atomic_dec32 using APR mutexes which will only work if APR is properly initialized. What appears to be happening in the crash is that APR has been terminated before the call to apr_atomic_dec32 and then apr_atomic_dec32 segfaults. Possibly remedies would be: 1. If running Solaris 10, modify either APR or log4cxx to use atomic_inc and atomic_dec. 2. If contention is not an issue, replace the atomic decrement with a simple --ref. 3. Determine why APR is terminating before the last object is reclaimed. It may be that APR is terminating earlier than expected on other platforms, it is just not noticed since apr_atomic_dec32 isn't dependent on APR being properly initialized on those platforms. Version of Solaris, processor type, compiler vendor and versions, etc would be helpful.
Re: Rolling File appender with compression doesn't seem to work
On Apr 29, 2008, at 2:41 PM, Dale King wrote: Yes, that was the issue. If it can't do the compression it should default to behaving as though the compression suffix is not there. I'm thinking the current behavior is likely due to copying the log4j implementation where failure of GzipOutputStream was not likely, so the failure scenario was not as graceful as it could be. It would also be a better idea to use the zlib library instead of spawning out to command line apps. Linux users will most likely already have zlib installed. For Windoze you can use the dll version of zlib and if the dll isn't there don't do the compression. I looked at the zlib license and that does not appear to be a stumbling block. If it had been GPL'd or LGPL'd, then spawning would likely be the only option. For the behavior that you described for Windows, that would involve LoadLibrary, GetProcAddress and the like (done by the equivalent APR methods) and zlib.dll would have to be on the path. The seems a lot of work for a likely failure. Using the zip methods in SHELL32.DLL would be much more likely to succeed. Wouldn't give you gz support which could still be done with spawning gzip. If someone wants to work on this, file a bug report and go for it. However, I don't see it coming to the top of my stack anytime soon. BTW, a documentation bug. The API documentation for TimeBasedRollingPolicy is missing the % sign before the d for specifying the FileNamePattern. It gives an example with: /wombat/folder/foo.d which should really be: /wombat/folder/foo.%d The source code comments have foo.%d. Apparently, the % gets dropped when Doxygen builds the site.
Re: Urgent: log4cxx 0.10.0 build on HP Unix build problem
On Apr 25, 2008, at 6:49 AM, Chakravarthula, Krishnamurthy wrote:
I get the following error when I build log4cxx 0.10.0. Please advice.
Did anybody get this working on HP Unix. If so, can you please pass on
the configurations and build steps.
objectptr.cpp: In static member function 'static void*
log4cxx::helpers::ObjectPtrBase::exchange(void**, void*)':
objectptr.cpp:41: error: cast from 'void*' to 'apr_uint32_t' loses
precisiongmake[3]: *** [objectptr.lo] Error 1
gmake[3]: Leaving directory
`/u/zztstkqa/jen/apache-log4cxx-0.10.0/src/main/cpp'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/u/zztstkqa/jen/apache-log4cxx-0.10.0/src/main'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/u/zztstkqa/jen/apache-log4cxx-0.10.0/
src'
gmake: *** [all-recursive] Error 1
Glad you got past the APR build problems.
The code that is failing to compile is this little chunk which is
called by the ObjectPtrTT template during assignment operations to
exchange the new and old values. It is preferable, but not absolutely
essential, that this exchange be atomic, so #if's are used to check
for the presence of atomic exchange methods.
The problem is that the middle chunk in the following code fragment is
active, but doesn't compile. If the APR configuration has detected
that void* is 4 bytes in size, then apr_atomic_xchg32 is used. The
compilation error indicates that void* can't be cast to apr_uint32_t
which is a 32-bit unsigned integer which you'd expect would be able to
hold a void* if void* was 4 bytes in size.
void* ObjectPtrBase::exchange(void** destination, void* newValue) {
#if _WIN32 (!defined(_MSC_VER) || _MSC_VER = 1300)
return InterlockedExchangePointer(destination, newValue);
#elif APR_SIZEOF_VOIDP == 4
return (void*) apr_atomic_xchg32((volatile apr_uint32_t*)
destination,
(apr_uint32_t) newValue);
#else
void* oldValue = *destination;
*destination = newValue;
return oldValue;
#endif
You could work around the compile problem, by modifying the #elif so
that the last fragment is active. Either a hack
#elif 0
or a refinement of the condition (which please submit back to the list)
#elif APR_SIZEOF_VOIDP == 4 !defined(SOMEFLAG)
However, the compile error is problematic since it suggests that APR
might have falsely detected a 32-bit void* when void* is 64-bit or APR
was compiled as a 32-bit app and log4cxx is being built as a 64-bit
app. In either case, bad things would be likely.
If you thought that you were building a 64-bit APR and
APR_SIZEOF_VOIDP == 4, then something is wrong in APR's configure on
your platform and you should raise the issue on the [EMAIL PROTECTED] mailing
list.
Re: log4cxx 0.10.0 dependency on libxml2
On Apr 24, 2008, at 2:35 AM, Chakravarthula, Krishnamurthy wrote: Experts, If I want to use log4j.xml with log4cxx 0.10.0, do I need libxml2 or any third part software? We want to use log4cxx for our product and want to evaluate if we need to license for libxml2 (for internal legal purposes). If there is a dependency on libxml2 then we may want to use log4cxx.properties file instead of log4j.xml. Please advice. Regards Krishna Apache log4cxx 0.10.0 does not have a dependency on libxml2. It has required dependencies on APR and APR-Util which are both licensed under the Apache Software License. APR-Util provides an XML parsing API that is implemented with Expat (either bundled or referenced depending on platform and build options) and the DOMConfigurator was rewritten between 0.9.7 and 0.10.0 to switch from libxml2 to APR- Util's XML API. Expat its own license which is very permissive and is acceptable for use in Apache projects.
Re: log4cxx 0.10.0 build on HP Unix build problem
On Apr 23, 2008, at 10:18 AM, Chakravarthula, Krishnamurthy wrote: Experts, I want to build log4cxx on HP Unix 11.11. I am using apr 1.2.12, apr-util 1.2.12. Build apr ./configure gmake Build apr-util ./configure –with-apr=pathto apr gmake I would try installling or building expat (http:// expat.sourceforge.net) if it not installed and then adding a --with- expat to the APR-util configure command. If you still have problem building APR-Util after that, you may get a better response from the [EMAIL PROTECTED] mailing list.
Re: Building problems on windows
On Apr 22, 2008, at 8:03 AM, Павел Кудинов wrote: ant clean didn't help. The problem is still exactly the same. APR compiles before log4cxx and errors occurre on linkage step... Hopefully, I fill find time to try a Win64 build myself tomorrow. I'm still thinking the most likely cause of the problem is inappropriately linking with an APR library compiled for Win32. The Ant build tries to find libraries that already been built with Visual Studio project files provided by APR. I would first try adding an - Dfind=false to the Ant command which will suppress attempting to locate existing libraries and if that doesn't work, try deleting the APR and APR-util directories and rebuilding.
Re: Building problems on windows
On Apr 21, 2008, at 4:02 AM, Павел Кудинов wrote: Thanks! I've solved first problem, but I cannot compile log4cxx in 64 bits as you said... Compilation step is ok, without errors. Errors are starting to fall on linkage step: The link step is failing to find APR provided methods. Possibly APR was compiled before you switched to 64-bit and you are finding a stale 32-bit version of APR. You may want to do an ant clean to delete any previous compiled object files or libraries.
Re: Building problems on windows
On Apr 20, 2008, at 7:30 AM, Павел Кудинов wrote: Hello everybody! Can you please help me with my questions? First, I have a problem building the last SVN version on Windows 2003 with VS2005. After some manipulations I finally made ANT compiling all this, but there is a compilation error: [cc] defaultconfigurator.cpp [cc] propertyresourcebundle.cpp [cc] thread.cpp [cc] E:\logger\log4cxx-head\src \main\cpp\thread.cpp(96) : error C2065: 'log4cxx_thread_t' : undeclared identifier [cc] E:\logger\log4cxx-head\src\main\cpp\thread.cpp(96) : error C2597: illegal reference to non-static member 'log4cxx::helpers::Thread::thread' [cc] E:\logger\log4cxx-head\src\main\cpp\thread.cpp(96) : error C2568: '*' : unable to resolve function overload [cc] unable to recover from previous error(s); stopping compilation [cc] socket.cpp [cc] xmllayout.cpp Either delete thread.cpp, do a fresh checkout or use log4cxx-0.10.0. thread.cpp was renamed threadcxx.cpp to avoid an object file name collision when both APR (which has a thread.c) and log4cxx are both compiled in the same IDE project. this is just a part of all process, as you see. I'm using the last version of APR and APR-UTIL (1.2.12) if this information helps. Command to run the compilation is: ant -Dwith-apr=e:/logger/log4cxx-head/apr-1.2.12 -Dwith-apr-util=e:/ logger/log4cxx-head/apr-util-1.2.12 -Ddebug=false The same things happening building in DEBUG mode. The second question is about 64bit machine support. Can you please describe how can I build all that on x64 machine? Does ANT support this feature? It should be as simple as running vcvarsall with the proper arguments instead of running vcvars32 to set up the path and environment variables before running Ant. See http://msdn2.microsoft.com/en-us/library/x4d2c09s(VS.80).aspx . Unit tests should fail if you build a 64-bit executable on a 32- bit OS, but the compile and link steps should work fine.
Re: MDC::put won't overwrite an existing value
On Apr 16, 2008, at 10:33 AM, Jacob L. Anawalt wrote: Dale King wrote: MDC::put( key, value1 ); MDC::put( key, value2 ); Without a code example, I must ask; are these MDC::put calls in the same thread right next to each other? The attached program correctly swaps keys in 0.9.7. I don't have an installed 0.10.0 build handy at the moment. There is no MDC test in the test suite and thread-local storage was rewritten in 0.10.0, so a regression from 0.9.7 is definitely possible. Took a while to find an explicit description of what happens when you call std::map::insert with a duplicate key, but section 17.4.1.7 of Stroustrup's The C++ Programming Language: Special Edition on top of page 488 says: .. insertion takes place only if there is not already an element in the m (map) with that key. The code in threadspecificdata.cpp just does an insert and does not check the return value to see if the insert was successful. Looks like we got caught by a difference between the STL and Java map behaviors. Either file a bug report or I'll do it and will port any appropriate log4j MDC tests over and fix the issue in a few days.
Re: should log4cxx protect itself from exceptions thrown by appenders?
On Apr 14, 2008, at 12:26 PM, J.T. Conklin wrote: Hi, When an appender's doAppend method throws an exception, it unwinds through the call stack. At the very least, this means that the log message won't be passed to any other appenders that might otherwise process it. It seems to me that log4cxx needs to protect calls to doAppend with a try/catch(...) block that squelches the errant exception. In my case, the exception escaped all the way up to a -log() call from one of my destructors, which caused bad things to happen... --jtc -- J.T. Conklin I don't have time to explore at the moment (the US government has me on its annual April 15th deadline), however it is likely that you are seeing a design that is directly carried over from log4j. In general, log4cxx tries to maintain a very similar design to log4j, so if log4j doesn't have a try/catch block, then log4cxx would not. If there is not a try/catch block in log4j, then the contract with the appender is that it not throw an exception from its doAppend block. It would be good to know which of the following category your problem falls into: 1. You are using a custom appender that throws an exception. The log4cxx dispatching code does not catch the exception. The log4j and log4cxx dispatching logics are consistent. Resolution: catch the exception within your appender. 2. You are using a log4cxx provided appender that throws an exception where the log4j equivalent does not. The log4cxx dispatch code does not catch the exception. The log4j and log4cxx dispatching logics are consistent. Resolution: Fix the log4cxx appender. 3. You are using a log4cxx provided appender that throws an exception as does the log4j equivalent. The log4cxx dispatch code does not catch the exception, but the log4j dispatch code would. Resolution: Fix the log4cxx dispatch code. 4. You are using a log4cxx provided appender that throws an exception as does the log4j equivalent. Neither log4cxx and log4j catch the exception. Resolution: Find a resolution to the problem for log4j and then port to log4cxx.
Re: log4cxx 0.10.0 Solaris build problem
On Apr 14, 2008, at 8:37 AM, Chakravarthula, Krishnamurthy wrote: Experts, When I am building log4cxx 0.10.0 on Solaris and I get the following errors. Please advice. [cc] __divdi30x174 ../ static/libapr-1.a(thread_cond.o) [cc] __divdi30x3c../ static/libapr-1.a(waitio.o) [cc] __divdi30x74../ static/libapr-1.a(waitio.o) [cc] __divdi30x8cc ../ static/libapr-1.a(apr_strings.o) [cc] __divdi30x120 ../ static/libapr-1.a(proc_mutex.o) [cc] ld: fatal: relocations remain against allocatable but non-writable sections [cc] collect2: ld returned 1 exit status BUILD FAILED /u/zztstkqa/jen/apache-log4cxx-0.10.0/build.xml:548: gcc failed with return code 1 Regards, Krishna Try adding a -Duse-pic=true to your command line or use the autotools build. The Ant build does not attempt to detect whether the compiler needs an explicit instruction to create relocatable code.
Re: Additional patterns possible?
On Apr 11, 2008, at 1:28 PM, Patrick Lannigan wrote: In a project that uses log4net, I have successfully added the pattern demonstrated to access Windows Special folders http://mail-archives.apache.org/mod_mbox/logging-log4net-user/200506.mbox/[EMAIL PROTECTED] I am now trying to do the same with log4cxx, but seem to be running into some roadblocks. Is it possible to produce this same result in log4cxx? If so, can an example be given to show how the log4cxx version would differ from log4net? Could you explain your use case? The most obvious one to me is to be able to use a folder path in a configuration file to specify the location of a log file, but that isn't consistent with the log4net example. The location of special folders should not change during a run, so I don't see the value in adding it as a converter for the pattern layout. It would just be simpler to output the value of the special folders as INFO logging requests at the start of the run instead of evaluating them over and over during the layout of messages.
Re: Newbie question: Compiling log4cxx 0.10.0 RC at Window XP Visual studio 2003 without Ant?
On Mar 30, 2008, at 10:28 AM, Beni Bilme wrote: Hi, I have checkout the log4cxx from http://svn.apache.org/viewcvs.cgi/logging/log4cxx/trunk. In windows, I have not been able to find a visual studio project file and left to Ant build. I had to install jdk, ant. I download apr stuff but realized that there are no binary versions available. Besides I still have to download some cpptask, ant contrib stuff. While doing this, I think that building this library should not be that complicated. I believe I am missing something. I just want to use this library. It seems that to build it I have install and configure lots of stuff which I do not use any of them in my development needs. Isn't there a simpler way to compile this library under visual studio 2003. A project file could be very helpful. I used this library in an c++ application whose development environment is lost, and I am trying to setup the development environment again. This is the only module that resist compile. I am quite sure that I am missing something and appreciate if someone can point it out. How can I compile this library without needing ant and all its related dependencies. Any comment much appreciated. Generated project files for Visual Studio 6 and Apple Xcode 2.4 are provided in the log4cxx 0.10.0 release candidates (there will be an RC7 announcement shortly). These files aren't in the SVN, since they are generated from the Ant build script. See site/building/ vstudio.html in the release candidate for details on setting up the build for Visual Studio. The project web site will be updated when a release candidate is accepted by the project.
Re: Help!: log4cxx\helpers\tchar.h(59) error snprintf identifier not found visual studio 2003
On Mar 31, 2008, at 3:26 AM, bilinmek istemiyor wrote: Hello, I have compiled the 0.9.7 version under visual studio 2003 by using the supplied visual studio project file under msvc. There was misleading instructions in the INSTALL file which was not valid. I just open the project file and build the project file without making any changes. Unfortunately while compiling my application I receive the error that I report in the subject line. There is conditional compilation in tchar file which depends on WIN32 macro. The compiler somehow does not select the right branch. I see that WIN32 defined in project preprocessor settings. Any insight much appreciated. Using log4cxx 0.9.7 has long been strongly discouraged for new users. We can provide no support for that version and strongly encourage new users to use the SVN HEAD. We are hopefully only days away from a 0.10.0 release. We would appreciate your using the current 0.10.0 release candidate and providing any feedback.
[VOTE] log4cxx-0.10.0 RC8
src/test/cpp/logunit.cpp in RC7 (and in all previous 0.10.0 RC's) is missing an #include locale.h that will cause a make check to fail to compile with Sun Studio 11, but does not apparently affect the other platforms. I do not see that defect sufficient to recall RC7, however I've prepared an RC8 with just that fix to consider as an alternative to RC7. Given personal time constraints, I do not have the option of extending the voting window to allow the normal 72 hours on RC8 and am setting the end time on the RC8 vote to coincide with the RC7 vote, which results in a voting window of approximately 57 hours for RC8. Unless the candidate is withdrawn, voting should be open until 08:20 GMT 2008-04-03. All discussion should occur on [EMAIL PROTECTED] . You may vote for releasing both RC7 and RC8. If both votes pass, RC8 will be released as Apache log4cxx 0.10.0. If only RC7 passes, then RC7 will be released as Apache log4cxx 0.10.0. If neither vote reaches quorum, the next time I will be able to prepare a release candidate will be mid-April. log4cxx 0.10.0 RC8 is now available for review for release on the unofficial builds area. This release candidate is strictly provided for consideration for release, may be withdrawn and will be removed from the publication location at the conclusion of the voting period. RC8 is currently available at: http://people.apache.org/builds/logging/log4cxx/0.10.0/apache-log4cxx-0.10.0-rc8.tar.gz MD5(apache-log4cxx-0.10.0-rc8.tar.gz)= b30ffb8da3665178e68940ff7a61084c http://people.apache.org/builds/logging/log4cxx/0.10.0/apache-log4cxx-0.10.0-rc8.zip MD5(apache-log4cxx-0.10.0-rc8.zip)= 9dd7eefcb9b73a2ef25b9e7ef7eadc2a The corresponding web content can be viewed directly from the staging SVN: http://svn.apache.org/repos/asf/logging/site/trunk/docs/log4cxx/index.html The corresponding source is available at: svn co http://svn.apache.org/repos/asf/logging/log4cxx/tags/v0_10_0-rc8 See the RC7 vote announcement for all other notes.
Re: wstring message failed to write to file
On Mar 21, 2008, at 4:40 AM, Piotr Wozniak wrote:
Hi,
I started to using log4cxx recently and I have problem to write
wstring messages containing any local character, it just stops to
write to file when receiving first of it until I restart application.
I stepped into through sources and it tries to convert msg to locale
and sets error flad on file stream when receiving first not
convertable chracter. I don't know how to fix it.
Could you please help?
Regards
Piotr
There is a lot of missing detail, could you answer the following:
Are you using the current SVN HEAD or 0.10.0 RC2 (very similar and
either would be okay)? If you are using a log4cxx 0.9.7, please
upgrade.
What operating system are you using? The code to perform the
conversion is substantially different between platforms.
What are your locale settings? (locale on Unix OS's, Control Panel/
Regional Settings on Windows).
What compiler?
What build method?
Do the unit tests run successfully?
What is the content of your src/main/include/log4cxx/private/
log4cxx_private.h?
What specific line is setting an error flag and what is the value?
If log4cxx encounters a character that can not be represented in the
current code page (for example, an asian character attempted to be
written to ISO-8859-1), it should replace it with a loss character
('?').
It would be good to understand the problem that you are encountering,
but if you are just looking for a work-around, you could try
explicitly specifying the encoding attribute for the appender to
either UTF-8 or UTF-16 and avoid converting to the default encoding.
Probably best for you to log a bug report at http://issues.apache.org/jira
. After initially creating the file, then you can add attachments.
Re: Building log4cxx with VC8 using runtime library /MT
On Mar 20, 2008, at 3:50 AM, Andreas Grob wrote: Hi, Failed finding an option for ant to do it directly I did it hand made using the build-projects-vc8 option. For the libs apr, aprutil and log4cxx I open the properties dialog and changed the runtime library option to /MT (or /MTd for the debug lib). I've added an option to select the static C RTL as bug https://issues.apache.org/jira/browse/LOGCXX-254 . To build a static log4cxx library which uses the static multithreaded C RTL use: ant -Dlib.type=static -Druntime=static -Dfind=false A dynamic log4cxx library which uses the static C RTL is unsafe since the API passes STL strings over the DLL boundary which can easily result in strings being allocated by one C RTL and freed by another. The unit tests will fail quickly with heap corruption assertions or access violations. Building apr and aprutil works well. But log4cxx didn't link because there are missing dependencies. Well, not a big deal I had to add apr.lib and aprutil.lib to the additional dependencies option. should this not already be done by ant -Dbuild-projects-vc8? Unfortunately, the Microsoft Visual Studio.NET and later solution file (.sln) format is not obvious and cpptasks does not generate it like the VC6 .dsw file. I believe that I had some luck with a combination of a .dsw and .vcproj's, but since I wasn't planning on providing VC7 or later project files with the log4cxx 0.10.0 release, I didn't explore further. It looks like there is an analysis of the format at http://www.ondotnet.com/pub/a/dotnet/excerpt/vshacks_chap1/index.html?page=4 . I'm looking forward for log4cxx release 0.10.0! :-) RC3 hopefully on Monday.
Re: Use of operator
On Mar 18, 2008, at 10:25 AM, Stephen Bartnikowski wrote:
Hi Josh,
As far as I can tell support was dropped for those macros, which
made me sad
too. But it's not too hard to cook up some macros of your own. I did
it like
this:
#define LOGGING_DEBUG(message) { \
if ((*pLogger)-isDebugEnabled()) {\
log4cxx::logstream oss(*pLogger, log4cxx::Level::getDebug());\
oss.setLocation(LOG4CXX_LOCATION);\
oss message;\
oss.end_message();}}
This assumes you have the following declared and initialized:
log4cxx::LoggerPtr* pLogger;
Hope this helps you out. I don't know if there's an official way for
doing
this.
- Stephen
Support for operator in the logging macros was restored last
September. It had been dropped since it was not obvious how to allow
the macros to work with both wide and byte character strings, but a
lot of experimentation hopefully results in a reasonable solution that
avoids the surprising expensive cost of std::basic_ostream
construction for simple streams and uses the compiler to determine
whether to use wide characters based on the first argument.
logstream and the insertional operator support inside the LOG4CXX_
macros serve different goals. The logstream was designed so you could
pass it into methods that expected a std::basic_ostream or you could
perform a complicated set up involving field widths etc and then reuse
it multiple times. The insertion operator support is to simplify
formatting that occurs within the scope of one logging request.
Steven, it would be helpful if you could redefine your current macros
in terms of the LOG4CXX_ macros and see if there are any unexpected
problems.
I'll add some text to the documentation before building the next
release candidate.
