logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Comments on HierarchyEventListener implementation details and other junk
Date Sat, 10 Sep 2011 05:52:49 GMT

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:
>            LOG4CXX_CAST_ENTRY(SubversiveASHEL)
>            LOG4CXX_CAST_ENTRY(HierarchyEventListener)
>    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

View raw message