extra qualities.

My problem with such approach is that it forces me to create hierarchy of log events as subclasses of base log component.

not necessary
we could have Log being a potential wrapper.

Imaging that my application already provide hierarchy of events but they have no timestamps. How to log them? Should I use some WrapperSignal?��

Now imaging that application uses some library which provides events too. But this events are log entries themselves. What I will see in my logs?��

I will see mix of WrapperSignal's and normal events. It would be not easy to analize such log.

That's why I want unified log entries. I would model it with single class LogEntry which nobody needs to subclass. It would contain logging domain information: timestamp, importance level, user message and whatever. And it would have content property to keep logging object. So our tools can rely on this structure to make it easy to work with logs. And when anybody will look at particular log he will be sure that logging object is inside "content" variables of each record