2016-04-27 21:12 GMT+02:00 stepharo <steph...@free.fr>: > 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.
But what about my example below? > 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. > > Do you think it is not problem? > > 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 > >
