Ceki & Curt,
Thanks for your prompt replies.
Using a customised repository selector seems an overkill for my needs, but it's
good to know I can do it if I need to.
I got around my problem by using c++ dynamic_cast to decide between creating a
customised logger or a log4cxx::Logger
(I could probably do better there had the log4cxx::Logger::forcedLog been
virtual, but since it is not
I have to use an explicit logger pointer type to invoke the desired one - the
one where I set extra properties on the created LoggingEvent)
BTW - DB stands for my company initials, not for Database (the domain name "db"
stands for that as well...).
As I mentioned several emails ago I did derive a SyslogLayout (to
use with log4cxx SyslogAppender), but needed more attributes on the
LoggingEvent,
a class which was meant to be extended according to its source doco,
but was not designed for that purpose according to its interface...
Thanks again,
Barak
________________________
Barak Simon
GED IT Core Platform
Deutsche Bank
190 George St. Sydney, 2000
Phone +61 2 925 85070
Fax +61 2 925 95050
[EMAIL PROTECTED]
To:
[email protected]
15/12/2004 07:36 cc:
Please respond to Subject: Re: Customised Loggers
- an interesting and difficult problem
log4cxx-user
At 11:59 PM 12/13/2004, Barak Simon wrote:
>Hi,
>I have an interesting problem:
>
>I have derived a customised logger, say, DBLogger from the log4cxx::Logger
>class, which is using a customised factory, say, DBFactory.
>We have a thin layer on top of log4cxx with our own Logger class
>encapsulating the underlying log4cxx logger class, or in that case,
>encapsulating the DBLogger extension class. We also have a LogManager of
>our own which handles our map of wrapper loggers by their names.
>
>The Problem:
>It seems that whenever a logger name is defined in a log4cxx configuration
>file, is actually being created dynamically by log4cxx using of course
>the default factory rather than our own DBFactory class.
>When we come to create this logger (i.e. when the user actually wants to
>log with the logger), though this logger is not in our own logmanager map
>at that stage
>it is already in log4cxx::LogManager map, so we get back an already
>existing log4cxx::Logger, and effectively try to cast it into a customised
>DBLogger
>(since we have a member of DBLogger inside each wrapper logger), which of
>course results with a zeroed pointer and a segmentation fault.
>
>Now, I know that one can write <categoryFactory class="DBFactory"/> in the
>configuration file to tell log4cxx to use DBFactory for the loggers
>it needs to create dynamically, but that puts too much responsibility on
>our users, which may get to a lot of trouble if they forgot to set it.
>(even if we can robustly prevent the segmentation fault, we are enforced
>to use Logger instead of DBLogger in this case).
As Curt mentioned, if DBLogger is for Database logging, then using a
DBAppender is probably much more appropriate than extending Logger.
Assuming DBLogger performs some other function which may not be
accomplished by the traditional extensions point (appender, layout),
then your questions are quite well put. In the log4j project, for the
reasons you mention, we avoid letting the user to specify her logger
factory at the level of a single logger. The user can specify a logger
factory at the level of the entire logger hierarchy with the help of a
custom repository selector. The repository selector return a specific
logger hierarchy and this hierarchy is responsible for creating loggers
of a given type.
The basic idea is explained here:
http://www.qos.ch/logging/sc.jsp
I hope this helps,
>Thanks,
>Barak
>
>--
--
Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
