Re: No Virtual Destructor for LoggingEvent

Hi again,
I have just noticed that the LoggingEvent class contains a 'properties' map,
and provides getter and setter for it.

Is using that (instead of deriving from LoggingEvent) a feasible solution?

What I think of is deriving a customised logger, and then overloading the 
forcedLog methods, such
that they can accept an extra 'properties' structure to be used for initing the 
newly created event
before calling callAppenders.

Please let me know your thoughts,
Tnx, Barak
________________________
Barak Simon
GED IT Core Platform
190 George St. Sydney, 2000
Phone +61 2 925 85070
Fax      +61 2 925 95050


                                                                                
                                                                        
                      barak.simon+exter                                         
                                                                        
                      nal@xxxxxx               To:       
log4cxx-user@xxxxxxxxxxxxxxxxxx                                                 
               
                                               cc:                              
                                                                        
                      09/12/2004 16:55         Subject:  Re: No Virtual 
Destructor for LoggingEvent                                                     
                      Please respond to                                         
                                                                        
                      log4cxx-user                                              
                                                                        
                                                                                
                                                                        
                                                                                
                                                                        





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



                      carnold@xxxxxxxxx
                      r.com                    To:       
log4cxx-user@xxxxxxxxxxxxxxxxxx
                                               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.







--

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.