Affects Version/s: None
Fix Version/s: 2.0
Security Level: Public (Public: Anyone can view)
KULRICE-10178 Remove SessionDocumentService from KRAD KULRICE-5005 Remove getDefaultCountry from CountryService KULRICE-5121 Remove JsValue from ValidCharactersConstraint KULRICE-1767 Remove org.kuali.core.util.UnitTestSqlDao from Rice KULRICE-3381 Remove "setSearchableAttributes" from the DocumentSearchGenerator KULRICE-1996 Remove lockCode from DocumentRouteHeaderValue KULRICE-1994 Remove overrideIndicator from DocumentRouteHeaderValue KULRICE-2537 Remove KEWUserNotFoundException from the codebase KULRICE-2248 Remove KOM module from Rice KULRICE-12617 Remove updateActionAttributes from AgendaBoServiceImpl
KAI Review Status:Not Required
KTI Review Status:Not Required
The rice team would like to remove the following methods from BusinessObjectBase
toStringMapper() - abstract method that clients must override and fill in with all the field names/values in their BO, used by toString.
toStringBuilder() - protected method that is used by toString, clients generally do not override
Both methods are troublesome for a few reasons:
1) toStringMapper gets out-of-date really quickly. For example when a new field is added to a BO often times the developer forgets to add the field to the toStringMapper method. KC in some cases created unit tests counting the fields in map returned from the toStringMapper versus the field count in a BO. Rice also has unit tests to make sure certain fields are present in the map returned from the toStringMapper. This is crazy!
2) toStringBuilder does not handle recursive/cyclic references so devs have to be careful not to introduce infinite recursion.
3) toStringMapper is just more boilerplate!
We would like to remove these methods and replace the toString method with a default implementation that does the following:
public String toString()
We've tested this implementation and it does work with recursive/cyclic references. If client apps want to do their own thing with toString they would be free to override our base implementation.
The only downside we can think of is with performance (reflection based, lazy proxies) but really toString is mainly used for debugging/logging purposes. Following good logging practices (ie code guards, correct levels) should mitigate any problems.