2016-04-28 14:51 GMT+02:00 Tudor Girba <[email protected]>: > It is not the most elegant solution, but it is very malleable and good > enough for debugging purposes. If we would have instance-based filtering > for announcements, we could filter based on that without any extra effort. > Also, if we would have a composition mechanism in place, we could build > these objects with a more elegant API. > > Regarding your statement of logging domain objects, you will have to store > these objects with the additional information somewhere, and that will be a > wrapper class. I do not see the difference with the Signal. >
Difference with Beacon is that users will not depends on objects from logging library. Nobody needs to subclass core components like Signal. Instead domain objects will be added to logs inside general LogEntry instances which will be hidden from user and only available inside logs. And LogEntry will allow include additional information to itself by appropriate logging API. Question is: does it better? And this is what problem I see around Beacon: Beacon proposes to design log entries as events, as subclasses of BeaconSignal. If nothing else exists it is good. We will see in logs collection of such events. But what to do with existing domain events which has no relation to logs? How to log them if we decide to do it? They can be added to log inside WrapperSignal. But then we will see in logs mix of normal events which created specially for logs and WrapperSignal's containing original application events. But both type of events belong to same application. We definitely want to see them and to work with them in same way everywhere (especially inside logs) Tudor what do you think about this problem? Maybe I misunderstood Beacon.
