Hi,
If this class is not meant for extension then why does Log4j doco say:
(1) "This class is of concern to those wishing to extend log4j."
Do they mean by that log4j developers rather than users - Sounds a bit bizarre
to me...
(2) Why did they not use "final"?
The point is that not being able to add your own customised fields, is, I
think, limiting significantly what one can do.
In my case, I have derived a SyslogLayout from PatternLayout, so as to be able
to prepend and append
some specific information to the syslog messages, information which is expected
by our existing monitoring systems.
But at that stage I can only use the data populated in LoggingEvent (or any
other data which is more or less global in its nature).
What I cannot do (but need to) is to get event-contextual data, e.g. event-id,
if we want to add such data per every logged message.
Unless I am missing the better/intended way of doing what I want, I truly think
this is a harsh limitation,
but be happy to hear differing opinions.
Thanks again,
Barak
________________________
Barak Simon
GED IT Core Platform
190 George St. Sydney, 2000
Phone +61 2 925 85070
Fax +61 2 925 95050
[EMAIL PROTECTED]
r.com To:
[email protected]
cc:
09/12/2004 16:03 Subject: Re: No Virtual
Destructor for LoggingEvent
Please respond to
log4cxx-user
On Dec 8, 2004, at 10:12 PM, Barak Simon wrote:
> Hi,
> I need to extend LoggingEvent to set some extra information in it,
> but it seems that despite being stated in its doco:
> "This class is of concern to those wishing to extend log4cxx",
>
> the destructor is not virtual!
>
> I know that extending it and instantiating it in a customised Logger
> class will break at present the SocketAppender,
> but am willing to take that risk, hoping the SocketAppender future
> implementation will have a less strict format.
>
> Is there any chance the next release will virtualise the LoggingEvent
> destructor?
>
> Many thanks,
> Barak
> _____
I don't believe that LoggingEvent has any virtual functions (other than
those inherited from ObjectImpl) and is not designed for extension.
Item 15 in Effective Java is "Design and document for inheritance or
prohibit it". LoggingEvent is not designed or documented for
inheritance (and intentionally so). There isn't the C++ equivalent of
declaring LoggingEvent as "final", but if there were I would.
You can "extend" LoggingEvent by adding strings to the mapped
diagnostic context, but I assume that isn't satisifactory. If you'd
want to discuss your use cases, maybe we could find some maintainable
approach.
--
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.
