log4cpp-devel — technical discussions about the development of log4cpp

Re: [Log4cpp-devel] Updating for C++17 and 20

[<log...@li...>]

Hello, Jeff.

throw(..) specifications with the list inside are removed already, please
checkout current master branch.

In order to move project towards c++20, throw() should be removed or
preferably replaced with noexcept.
auto_ptr can also be replaced with unique_ptr ancestor, small code
adjustments are required.

However, there is the following  consequence of these changes: the project
will stop being compilable on the older platforms with outdated compilers
which I see an undesirable effect.

If folks around do not mind, we may try to move the project there. Or,
alternatively, think about probable solution including preprocessor's code
adjustment for both pre- and post- c++11 compilers.

Alex.

вс, 10 нояб. 2019, 2:06 <log...@li...>:

> Hi - is log4cpp pretty much dead, or, just stable I guess. Well, parts
> won't compile under a C++ 17 - conforming compiler, not even when used as
> binaries (ie, even the headers are wrong) and for C++20 they're entirely
> forbidden:
>
>
> https://stackoverflow.com/questions/47727108/are-dynamic-exception-specifications-invalid-in-c17#47727338
>
> The code compiles under 17 just fine if you simply remove all of the
> throw([...]) specifications, I can submit a pull request for that I guess.
> But we / someone should also get rid of the auto_ptr<>s. I thought of
> replacing them with unique_ptr<>s, but I'm afraid of subtle bugs due to
> possible different semantics. Any experts feel like taking that on?
>
> Jeff
>
>
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>

[Log4cpp-devel] Updating for C++17 and 20

[<log...@li...>]

Hi - is log4cpp pretty much dead, or, just stable I guess. Well, parts won't compile under a C++ 17 - conforming compiler, not even when used as binaries (ie, even the headers are wrong) and for C++20 they're entirely forbidden: 

https://stackoverflow.com/questions/47727108/are-dynamic-exception-specifications-invalid-in-c17#47727338

The code compiles under 17 just fine if you simply remove all of the throw([...]) specifications, I can submit a pull request for that I guess. But we / someone should also get rid of the auto_ptr<>s. I thought of replacing them with unique_ptr<>s, but I'm afraid of subtle bugs due to possible different semantics. Any experts feel like taking that on? 

Jeff

Re: [Log4cpp-devel] FileAppender::getFileName() API?

[<log...@li...>]

John,

you hit the right forum.
I would say that writing to the same file from different process was
not generally very good idea.
Depending on many circumstances your output might look like expected,
but sooner or later you most probably will see your log lines quite
intermixed and not readable.
For instance, depending on the buffering preferences, your calls will
be flushed to disk fully or partially, and without external
synchronization for the log file there is no guarantee for proper
result. Such sync although would be total overkill for the logging
purposes. Hiding filename from the user of the library in this case
looks like advice.
I would suggest you to log to different files with timestamps and sync
on them or to set up any kind of communication channel between your
processes and write to log file from only one process.

On Tue, Dec 22, 2015 at 6:43 PM,  <log...@li...> wrote:
>
> I see that FileAppender::_fileName is protected. It would be great if there
> were an accessor:
>
>
>     const std::string & FileAppender::getFileName() const {
>         return _fileName;
>     }
>
>
> I have some C++ code that invokes a python script (using popen) and I would
> like the python script to log to the same file as the calling C++ code. For
> this, I'd like to walk the appenders, and for any FileAppenders, ask them
> what their filename is, so I can pass the filename to my python script.
>
>
> Is this reasonable? Is this list the correct forum for asking for such a
> thing?
>
>
> -John Gregg
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>

[Log4cpp-devel] FileAppender::getFileName() API?

[<log...@li...>]

I see that FileAppender::_fileName is protected. It would be great if there were an accessor:


    const std::string & FileAppender::getFileName() const {
        return _fileName;
    }


I have some C++ code that invokes a python script (using popen) and I would like the python script to log to the same file as the calling C++ code. For this, I'd like to walk the appenders, and for any FileAppenders, ask them what their filename is, so I can pass the filename to my python script.


Is this reasonable? Is this list the correct forum for asking for such a thing?


-John Gregg

Re: [Log4cpp-devel] How does one "destroy" a category?

[<log...@li...>]

On 17/03/15 09:35, log...@li... wrote:
> On 3/16/15, 11:33 PM, "log...@li..." 
> <log...@li...> wrote:
> 
> 
>>
>> I'm doing some further research into this, NDC sounds closer to what I'm
>> after, however one things that concerns me is that it appears I need to
>> manually push my context onto it each time I enter a context rather than
>> just writing to an object that does this for me.
> 
> Yes, but you can wrap all that into your classes via c'tors and d'tors so 
> that it's automatic if you design things right.
> 
>> Basically what I'm after, is an object that I can hold either by
>> reference or pointer, that when I write to it, it applies the necessary
>> tagging to identify that line in the log and know where it came from.
> 
> You could also wrap the Category interface so that when you call methods 
> on it, it pushes/pops the NDC for you before calling the category methods.

Indeed, for now I'll see how the following goes.

	class LogContext {
		public:
			LogContext(log4cpp::Category& log,
					const std::string& context)
			: log(log)
			{
				log4cpp::NDC::push(context);
			}

			~LogContext()
			{
				log4cpp::NDC::pop();
			}

			log4cpp::Category&	log;
	};

The idea being it gets allocated on the stack, and will be popped off
when the function exits.  This might do the trick.
-- 
     _ ___             Stuart Longland - Systems Engineer
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au

Re: [Log4cpp-devel] How does one "destroy" a category?

[<log...@li...>]

On 3/16/15, 11:33 PM, "log...@li..." 
<log...@li...> wrote:


>
>I'm doing some further research into this, NDC sounds closer to what I'm
>after, however one things that concerns me is that it appears I need to
>manually push my context onto it each time I enter a context rather than
>just writing to an object that does this for me.

Yes, but you can wrap all that into your classes via c'tors and d'tors so 
that it's automatic if you design things right.

>Basically what I'm after, is an object that I can hold either by
>reference or pointer, that when I write to it, it applies the necessary
>tagging to identify that line in the log and know where it came from.

You could also wrap the Category interface so that when you call methods 
on it, it pushes/pops the NDC for you before calling the category methods.

-- Scott

Re: [Log4cpp-devel] How does one "destroy" a category?

[<log...@li...>]

Hi Scott and Alexander,
On 16/03/15 09:39, log...@li... wrote:
> On 3/15/15, 7:25 PM, "log...@li..." <log...@li...> wrote:
> 
>> It appears it would make sense for each transaction state machine to
>> have its own log category, as the log messages can then be grepped for
>> and it ensures *every* log message from that log instance will have the
>> ID prepended.
> 
> I think you want to use a diagnostic context, not a category. Just push and pop the ID with the NDC routines.
> 
> (And you can't really destroy a category, so that's why it's a bad choice to use that.)

On 16/03/15 15:57, log...@li... wrote:
> The categories in current design are seen as purposed for kind of static
> matters, those which do not actively come into the processing and leave
> it. There is static helper method to make their creation convenient and
> controlled. However, there is no destroy method since the pointer given
> out might still be kept somewhere else, out of log4cpp internals.
> If you'd like to have an unique id coming along with your log messages,
> you could take advantage of the NDC feature. It is exactly purposed for
> attaching kind of context to the log messages. It can be turned on and
> off from properties file without rebuilding, but note that is linked
> with a thread, and not with the particular category.
> If your processing is not thread-based, won't it be easier to log the id
> just as a part of the message itself?

I'm doing some further research into this, NDC sounds closer to what I'm
after, however one things that concerns me is that it appears I need to
manually push my context onto it each time I enter a context rather than
just writing to an object that does this for me.

Basically what I'm after, is an object that I can hold either by
reference or pointer, that when I write to it, it applies the necessary
tagging to identify that line in the log and know where it came from.

Categories aren't ideal, but it does achieve this in a structured
manner.  I don't have to remember to tell it that I'm in a transaction
state machine context (which may be in a separate thread) or have to
remember to remove it at the end.

I'll do some more digging and see what I can uncover, but this looks
like it gets at least part-way there.
-- 
     _ ___             Stuart Longland - Systems Engineer
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au

Re: [Log4cpp-devel] How does one "destroy" a category?

[<log...@li...>]

Hello Stuart,

The categories in current design are seen as purposed for kind of static
matters, those which do not actively come into the processing and leave it.
There is static helper method to make their creation convenient and
controlled. However, there is no destroy method since the pointer given out
might still be kept somewhere else, out of log4cpp internals.
If you'd like to have an unique id coming along with your log messages, you
could take advantage of the NDC feature. It is exactly purposed for
attaching kind of context to the log messages. It can be turned on and off
from properties file without rebuilding, but note that is linked with a
thread, and not with the particular category.
If your processing is not thread-based, won't it be easier to log the id
just as a part of the message itself?

Alexander.
 On Mar 16, 2015 3:26 AM, <log...@li...> wrote:

> Hi all,
>
> A silly question, I'm looking to use log4cpp for a data collection
> system I'm working on.
>
> To help in post mortem analysis it's often useful to separate out log
> messages by some common key to be able to piece out what happened.  The
> system starts multiple transaction state machines each identified by a
> unique ID, creating them at runtime.  They are one-shot, so once
> complete, the objects are freed.
>
> It appears it would make sense for each transaction state machine to
> have its own log category, as the log messages can then be grepped for
> and it ensures *every* log message from that log instance will have the
> ID prepended.
>
> It seems I can create as many category objects as I like, but what isn't
> clear is what happens to the category objects when they're no longer
> needed: I don't see any way to close them off or destroy them.  (I could
> call delete(&category); but I'm not sure where else the pointer may be
> used.)
>
> Is there a way to remove categories once they're no longer in use?
> Regards,
> --
>      _ ___             Stuart Longland - Systems Engineer
> \  /|_) |                           T: +61 7 3535 9619
>  \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
>    SYSTEMS    Milton QLD 4064       http://www.vrt.com.au
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>

Re: [Log4cpp-devel] How does one "destroy" a category?

[<log...@li...>]

On 3/15/15, 7:25 PM, "log...@li..." <log...@li...> wrote:

>It appears it would make sense for each transaction state machine to
>have its own log category, as the log messages can then be grepped for
>and it ensures *every* log message from that log instance will have the
>ID prepended.

I think you want to use a diagnostic context, not a category. Just push and pop the ID with the NDC routines.

(And you can't really destroy a category, so that's why it's a bad choice to use that.)

-- Scott

[Log4cpp-devel] How does one "destroy" a category?

[<log...@li...>]

Hi all,

A silly question, I'm looking to use log4cpp for a data collection
system I'm working on.

To help in post mortem analysis it's often useful to separate out log
messages by some common key to be able to piece out what happened.  The
system starts multiple transaction state machines each identified by a
unique ID, creating them at runtime.  They are one-shot, so once
complete, the objects are freed.

It appears it would make sense for each transaction state machine to
have its own log category, as the log messages can then be grepped for
and it ensures *every* log message from that log instance will have the
ID prepended.

It seems I can create as many category objects as I like, but what isn't
clear is what happens to the category objects when they're no longer
needed: I don't see any way to close them off or destroy them.  (I could
call delete(&category); but I'm not sure where else the pointer may be
used.)

Is there a way to remove categories once they're no longer in use?
Regards,
-- 
     _ ___             Stuart Longland - Systems Engineer
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au

Re: [Log4cpp-devel] multiple logger instances initialized from several properties files

[<log...@li...>]

On 2015-02-14 09:40, log...@li... wrote:
> Hello Sorin,
>
> When you say log4cplus, I suppose you mean log4cpp actually, don't you?

I'm very embarrassed, I actually meant log4cplus and I posted to the 
wrong mailing list. I apologize for that.

But I think the question holds for log4cpp too.

> The best thing I may suggest you is that your plugins do not initialize
> loggers (or even other resources) themselves, but instead provide API
> calls for the user of your plugin library. This way you avoid checks for
> sanity and have better control for your resources.

Yes, I thought of that too. The problem is that the my "plugins" are 
apache web server modules and the "user" is the apache web server. So 
apache will not invoke my API for log4(cpp|cplus) initialization. 
Moreover, I don't know the set of third party apache modules that 
co-exist in the web server and how they handle log4cpp properties files.

> Several loggers coexist fine as soon as they have different names. If
> you ask about ones having same names, you are putting loaded gun into
> your pocket. You could do tricks do determine the fact, but it is out of
> usage patterns for the library, and I would not advise you to do it.
> The common approach for logging is having single log4.properties file
> per process no matter how many libraries does it involve.

No, I don't have the requirement that the loggers have the same name. 
The logger name is configurable in my application. However I am 
concerned about initializing the logging system several times with 
several log4.properties files because each "plugin"/apache module ships 
with its own initialization and is unaware of the existence of the other 
properties file. I suppose that I'm relatively safe even when this 
happens. I suppose either the definitions (appenders, loggers) are 
merged or overwritten. After this happens, if each module has its own 
logger with a different name then everything should be fine. Maybe a 
small memory leak due to the multiple initializations, but it shouldn't 
be serious as it's a one-off event.

Best regards,
Sorin

Re: [Log4cpp-devel] multiple logger instances initialized from several properties files

[<log...@li...>]

Hello Sorin,

When you say log4cplus, I suppose you mean log4cpp actually, don't you?
The best thing I may suggest you is that your plugins do not initialize
loggers (or even other resources) themselves, but instead provide API calls
for the user of your plugin library. This way you avoid checks for sanity
and have better control for your resources.

Several loggers coexist fine as soon as they have different names. If you
ask about ones having same names, you are putting loaded gun into your
pocket. You could do tricks do determine the fact, but it is out of usage
patterns for the library, and I would not advise you to do it.
The common approach for logging is having single log4.properties file per
process no matter how many libraries does it involve.

Regards,
Alexander.
On Feb 11, 2015 6:45 PM, <log...@li...> wrote:

> Hello,
>
> I'm wondering if several logger instances may co-exist in the same
> process. Each logger instance is initialized from a different properties
> file.
>
> The use case is when I develop a plugin (a DSO in unix) that is loaded
> with dlopen in the process. I cannot know if another plugin uses
> log4cplus. Therefore both my plugin and a third party's plugin may
> invoke PropertyConfigurator::doConfigure(property_file) each with its
> own property_file. What would happen then?
>
> Is there a way to determine if the third party's module has already
> initialized the logging system and executed doConfigure(property_file)?
>
> Thank you,
> Sorin
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>

[Log4cpp-devel] multiple logger instances initialized from several properties files

[<log...@li...>]

Hello,

I'm wondering if several logger instances may co-exist in the same 
process. Each logger instance is initialized from a different properties 
file.

The use case is when I develop a plugin (a DSO in unix) that is loaded 
with dlopen in the process. I cannot know if another plugin uses 
log4cplus. Therefore both my plugin and a third party's plugin may 
invoke PropertyConfigurator::doConfigure(property_file) each with its 
own property_file. What would happen then?

Is there a way to determine if the third party's module has already 
initialized the logging system and executed doConfigure(property_file)?

Thank you,
Sorin

Re: [Log4cpp-devel] shutting down and reinit without leaking

[<log...@li...>]

On 01/09/2015 09:01 PM, log...@li... wrote:
> Hello Sorin,
>
> Thank you for your deep considerations.
> I agree that the graceful shutdown is missing in the library, though as
> weak excuse it is really rarely applied.
> Your a) seems pretty reasonable, I just have to check if it may cause
> any unexpected consequences.

Long time ago I have implemented graceful shutdown but didn't committed 
anything for reasons I don't remember now.

I will take a look on code tomorrow and comment Sorin's message too.

Re: [Log4cpp-devel] shutting down and reinit without leaking

[<log...@li...>]

Hello Sorin,

Thank you for your deep considerations.
I agree that the graceful shutdown is missing in the library, though as
weak excuse it is really rarely applied.
Your a) seems pretty reasonable, I just have to check if it may cause any
unexpected consequences.
DeleteAllCategories call could be made public, it is just that categories
and appenders are interconnected via pointers and therefore it probably
will be better to have cleanup method that will take care of them both.
Appenders might be shared. And not only at the instantiation time after
reading properties file, but programmatically later too. The log4cpp lib
does not make use of smart pointers, and it is not easy to determine
whether particular appender is shared. I will dedicate some time to
investigate it further, but if you have something already, please share
your findings too.

Regards,
Alexander
 On Jan 8, 2015 2:13 PM, <log...@li...> wrote:

> Hello,
>
> I would like to be able to initialise log4cpp from a properties file, to
> shut it down, to reinitialise it from another properties file etc.
>
> In my opinion, there are two problems with this approach:
>
> 1. Leaking Appenders: The Appenders are not owned by the Categories when
> the log system is initialised from a properties file. Therefore
> Category::shutdown does neither close nor destroy the Appenders. I could
> close them with Appender::closeAll but not destroy them.
>
> I could work around this problem by calling
> Category::getCurrentCategories() and then for each Category
> getAllAppenders() and then I destroy every Appender that is not owned by
> the Category. This works if the system is initialised exclusively from
> properties file as no Appender is owned by any Category. If, however,
> one Appender was owned by one Category, but not by another, then I would
> run the risk to destroy an Appender twice, once by my code and once by
> the destructor of the Category that owns it.
>
> 2. Leaking Categories: I could destroy all Categories by calling
> HierarchyMaintainer::deleteAllCategories(). One problem is that
> HierarchyMaintainer is an internal class, as the comments say, so I
> should not use it. Another problem is that deleteAllCategories()
> destroys the Categories in _categoryMap but does not clear the map.
> Thus, when the HierarchyMaintainer is destroyed automatically upon
> program exit the HierarchyMaintainer destructor attempts to destroy the
> already destroyed Categories and I get a segfault.
>
> I could work around this problem by implementing a
> log4cpp::Log4cppCleanup class (exploiting the "friend class
> Log4cppCleanup" feature in HierarchyMaintainer) and setting a shutdown
> handler (HierarchyMaintainer::register_shutdown_handler) that executes
> HierarchyMaintainer::_categoryMap.clear().
>
> So all in all I get the behaviour I want, but I have the feeling of
> forcing the lib.
>
> I would have preferred
>
> a) that deleteAllCategories cleared the _categoryMap. I think this is a
> bug.
>
> b) that deleteAllCategories was exported via a call to Category.
>
> c) that there was a straightforward way to destroy all Appenders that
> are not owned by the Categories.
>
> Best regards,
> Sorin
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>

[Log4cpp-devel] shutting down and reinit without leaking

[<log...@li...>]

Hello,

I would like to be able to initialise log4cpp from a properties file, to 
shut it down, to reinitialise it from another properties file etc.

In my opinion, there are two problems with this approach:

1. Leaking Appenders: The Appenders are not owned by the Categories when 
the log system is initialised from a properties file. Therefore 
Category::shutdown does neither close nor destroy the Appenders. I could 
close them with Appender::closeAll but not destroy them.

I could work around this problem by calling 
Category::getCurrentCategories() and then for each Category 
getAllAppenders() and then I destroy every Appender that is not owned by 
the Category. This works if the system is initialised exclusively from 
properties file as no Appender is owned by any Category. If, however, 
one Appender was owned by one Category, but not by another, then I would 
run the risk to destroy an Appender twice, once by my code and once by 
the destructor of the Category that owns it.

2. Leaking Categories: I could destroy all Categories by calling 
HierarchyMaintainer::deleteAllCategories(). One problem is that 
HierarchyMaintainer is an internal class, as the comments say, so I 
should not use it. Another problem is that deleteAllCategories() 
destroys the Categories in _categoryMap but does not clear the map. 
Thus, when the HierarchyMaintainer is destroyed automatically upon 
program exit the HierarchyMaintainer destructor attempts to destroy the 
already destroyed Categories and I get a segfault.

I could work around this problem by implementing a 
log4cpp::Log4cppCleanup class (exploiting the "friend class 
Log4cppCleanup" feature in HierarchyMaintainer) and setting a shutdown 
handler (HierarchyMaintainer::register_shutdown_handler) that executes 
HierarchyMaintainer::_categoryMap.clear().

So all in all I get the behaviour I want, but I have the feeling of 
forcing the lib.

I would have preferred

a) that deleteAllCategories cleared the _categoryMap. I think this is a bug.

b) that deleteAllCategories was exported via a call to Category.

c) that there was a straightforward way to destroy all Appenders that 
are not owned by the Categories.

Best regards,
Sorin

Re: [Log4cpp-devel] Issue building for an embedded target utilizing BuildRoot.

[Alexander <san...@gm...>]

Sean,

I guess the cause is that configure script does not recognize the options
you passed to. --prefix option serves for installation destination, please
make sure about that on root page http://log4cpp.sourceforge.net
You passed set of other options, but not this one.

Regards,
Alexander

[Log4cpp-devel] Issue building for an embedded target utilizing BuildRoot.

[Sean K. <sk...@ip...>]

Hi Guys,

I'm having an issue with building your lib for an embedded application. 
My issue is faily simple, I want to build ONLY the lib, none of the docs 
etc, but I can't seem to find the make directive to do that. I'm using 
the buildRoot system and here is my master make file as well as the 
error produced. Any input would be appreciated. As you can see I tried 
to keep docs off of my RFS image by configuring it to dump docs to the 
/tmp of the build system, but it doesn't seem to be working.

Thanks,
Sean

PS

Alexander was kind enough to promptly reply with:

 > Sean,
 >
 > Obviously, you are trying to install library and your account does 
not have enough permissions. Look for install word in your script and 
find out how to deal with it.There is mailing list for such questions 
actually. Please use it next
 > time, or even right now if my answer will not help you. Address is 
somewhere at sourceforge page for log4cpp.
 >
 > Regards,
 > Alexander.

FWIW other autotools projects more or less just work with BuildRoot. I 
have tried the following directive with my BuildRoot log4cpp package script:

LOG4CPP_CONFIGURE_CMDS= cd $(@D) && ls && ./autogen.sh && ./configure 
--program-prefix=$(STAGING_DIR)/usr/ --psdir=/tmp --pdfdir=/tmp 
--dvidir=/tmp --htmldir=/tmp --docdir="/tmp" \
--mandir=/tmp --infodir=/tmp

LOG4CPP_BUILD_CMDS = cd $(@D) && make

As you can see I'm trying to use the correct program-prefix for my 
target and I tell it to dump docs and things I don't need into /tmp so 
that they don't bloat my embedded image.

Still yeilds:

/usr/bin/install -c -m 644 
./man/man3/log4cpp_TimeStampComponent.3/tmp/man3/log4cpp::TimeStampComponent.3
/usr/bin/install -c -m 644 
./man/man3/log4cpp_TriggeringEventEvaluator.3/tmp/man3/log4cpp::TriggeringEventEvaluator.3
/usr/bin/install -c -m 644 
./man/man3/log4cpp_TriggeringEventEvaluatorFactory.3/tmp/man3/log4cpp::TriggeringEventEvaluatorFactory.3
/usr/bin/install -c -m 644 
./man/man3/log4cpp_width.3/tmp/man3/log4cpp::width.3
/usr/bin/install -c -m 644 
./man/man3/log4cpp_Win32DebugAppender.3/tmp/man3/log4cpp::Win32DebugAppender.3
/bin/bash ../config/mkinstalldirs /usr/local/doc/log4cpp-1.1
mkdir /usr/local/doc
mkdir: cannot create directory ‘/usr/local/doc’: Permission denied
mkdir /usr/local/doc/log4cpp-1.1
mkdir: cannot create directory ‘/usr/local/doc/log4cpp-1.1’: No such 
file or directory
make[4]: *** [install-data-local] Error 1

Something like <make installLib> is all I need. In the mean time I will 
try Alexander's advice.

Thanks again,
Sean

Re: [Log4cpp-devel] Problem Logging process id & fully qualified domain name using log4cpp

[Alexander <san...@gm...>]

Hello,

Log4cpp may log thread name for you automatically by using option %t
Full list of supported characters you may find on the start page
http://log4cpp.sf.net or in header file PatternLayout.hh
There is no such option as process id or fqdn, but I think you can solve
your task by using NDC (nested diagnostic contexts)

Kind regards,
Alexander.

[Log4cpp-devel] Problem Logging process id & fully qualified domain name using log4cpp

[Gagandeep S. P. <gag...@gm...>]

Hi ,
I need to log Process Id and  fully qualified domain name into my log file .

This is my sample log4cpp.conf file  -

log4j.rootCategory=DEBUG
log4j.category.cdrsumm_log=DEBUG,cdrsumm
log4j.category.cdrpersist_log=DEBUG,cdrpersist
log4j.category.cdrconv_log=DEBUG,cdrconv

log4j.appender.cdrsumm=org.apache.log4j.RollingFileAppender
log4j.appender.cdrsumm.fileName=logs/cdrsumm.log
log4j.appender.cdrsumm.maxFileSize=10000000
log4j.appender.cdrsumm.maxBackupIndex=20
log4j.appender.cdrsumm.layout=org.apache.log4j.PatternLayout
log4j.appender.cdrsumm.layout.ConversionPattern=%d{%Y-%m-%dT%H:%M:%S.%l%1Z}
%H PFCDRSUMM %p %E[%P]: %m%n



I need to log like -

2014-06-10T07:20:52.865GMT 123.abc.com PFCDRCONV ERROR cdconv[5022]:
Invalid data in CD file

where 123.abc.com is my fully qualified domain name & 5022 is my process id.

When I am runnig my application following error is generated -
terminate called after throwing an instance of 'log4cpp::ConfigureFailure'
  what():  unknown conversion specifier 'H' in '%d{%Y-%m-%dT%H:%M:%S.%l%1Z}
%H PFCDRSUMM %p %E[%P]: %m%n' at index 30
  what():  unknown conversion specifier 'P' in '%d{%Y-%m-%dT%H:%M:%S.%l%1Z}
%H PFCDRSUMM %p %E[%P]: %m%n' at index 30
Aborted

But when I remove %H & %P it logs fine but not Process ID & fully qualified
domain name.


Any help would be greatful.


Thanks & Regards,
Gagandeep Singh Panesar

Re: [Log4cpp-devel] Migration to a git repository

[Volker W. <Vol...@gm...>]

Hi Darko,

Thanks for your mail and the link to your git repo.
I think it is not the official one, is it? I didn't find a link to it on
the official log4cpp homepage.
I'd like to commit my changes to the official repo or an official fork.

Would it be possible to add a link to Darko's git repo from the log4cpp
homepage?

Regards,
Volker

On 05/21/2013 09:47 PM, Palic, Darko wrote:
> Hi Volker,
>
> I have already created a git repo.
> https://github.com/dpalic/log4cpp
>
> best regards,
> Darko
>
> On 05/20/2013 06:14 PM, Volker Wildi wrote:
>> Hi all,
>>
>> I stumbled over this project some time ago and made several changes
>> which I'd like to share with the community.
>> Unfortunately, I'm not familar with CVS and I think it's time to go
>> ahead with a SCM tool of the future such as git.
>>
>> I'd appreciate if this piece of software would be migrated to
>> github.com.
>>
>> What is your opinion?
>>
>> I'm looking forward to hearing from you!
>>
>> Thanks in advance!
>>
>> -Volker
>>
>> ------------------------------------------------------------------------------
>>
>> AlienVault Unified Security Management (USM) platform delivers complete
>> security visibility with the essential security capabilities. Easily and
>> efficiently configure, manage, and operate all of your security controls
>> from a single console and one unified framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>> _______________________________________________
>> Log4cpp-devel mailing list
>> Log...@li...
>> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>

Re: [Log4cpp-devel] Migration to a git repository

[Palic, D. <dar...@gm...>]

Hi Volker,

I have already created a git repo.
https://github.com/dpalic/log4cpp

best regards,
Darko

On 05/20/2013 06:14 PM, Volker Wildi wrote:
> Hi all,
>
> I stumbled over this project some time ago and made several changes
> which I'd like to share with the community.
> Unfortunately, I'm not familar with CVS and I think it's time to go
> ahead with a SCM tool of the future such as git.
>
> I'd appreciate if this piece of software would be migrated to github.com.
>
> What is your opinion?
>
> I'm looking forward to hearing from you!
>
> Thanks in advance!
>
> -Volker
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Migration to a git repository

[Volker W. <Vol...@gm...>]

Hi all,

I stumbled over this project some time ago and made several changes
which I'd like to share with the community.
Unfortunately, I'm not familar with CVS and I think it's time to go
ahead with a SCM tool of the future such as git.

I'd appreciate if this piece of software would be migrated to github.com.

What is your opinion?

I'm looking forward to hearing from you!

Thanks in advance!

-Volker

[Log4cpp-devel] RemoteSyslogAppender does not properly handle IP address

[Alexander <san...@gm...>]

Simon,
thank you for coming back and repeating of that bug, fix is commited into
cvs.
RemoteSyslogAppender.cpp, revision: 1.25
package log4cpp-1.1 can not be changed once it is released, but fix is in
current development branch now and will be included into next release.
Alexander.

Re: [Log4cpp-devel] CategoryStream

[Cantor, S. <can...@os...>]

On 10/15/12 12:55 PM, "Paul Dugas" <pa...@du...> wrote:
>
>My search skills must be failing me.  Been looking into this for a
>couple days with little luck.  Got a link or a search term I should be
>using other than log4cpp and CategoryStream?

Not that. Search for the compiler's generic error message info.

Or browse the clang FAQ material. I don't have a link handy.

-- Scott