Well, I think the missing point to understand why we have these different situations is the understanding of the developer’s mind. It is so diverse and unique from people to people, and because we do not have a policy on that, each developer is doing the best they know and think.
For instance, at first sight, the idea of calling the “toString” of an object to append its information in a log entry might be interesting. However, objects like the “VmInstance” are quite big and would probably clutter the log entry. In my opinion, for most log entries at the DEBUG/INFO/WARN levels the ID of the logged element should be more than enough to the operators/administrators to track down events or problems in the cloud. Others probably think the opposite, meaning that, only the ID is not enough and more details about the object in an event are required. In the absence of a policy to regulate this, both are valid arguments under different perspectives. On Wed, Apr 12, 2017 at 11:49 AM, Rene Moser <m...@renemoser.net> wrote: > Hi > > In logs we see all kind variations how an object is printed to the > users. E.g. for VMs we have seen, the DB ID, UUID, internal name, name > etc. in different debug log messages. And this makes debugging harder > than it should. > > I wondered, why don't we just use the "toString()" in VO classes. > > E.g in this PR > https://github.com/apache/cloudstack/pull/1252/files#diff- > ab243638abf88707693d464b3b1836feR1503 > > > We see a: > > s_logger.debug("Host is in PrepareForMaintenance state - Stop VM > operation on the VM id: " + vm.getId() + " is not allowed"); > > > With a toString in the VO class of the VM this would turn into > > s_logger.debug("Host is in PrepareForMaintenance state - Stop VM > operation on the VM: " + vm + " is not allowed"); > > Did I miss anything? > > René > -- Rafael Weingärtner
