https://bz.apache.org/bugzilla/show_bug.cgi?id=60381
--- Comment #3 from Michael Osipov <1983-01...@gmx.net> --- (In reply to Mark Thomas from comment #2) > The toString() implementations have been pretty much unchanged since the > lifecycle refactoring in 7.0.x. While users shouldn't not be expecting these > to be in any particular format, the chances are that there that some users > are expecting the current format. Therefore, we can look at this for trunk > but I don't think it should be back-ported. I do not even expect some specific format, but rather a consistent approach. Don't you think it is worthwile to port back to 8.5? This is going to be supported for a long time compared to 6.0/7.0. > My current thinking for a standardised format is: > SimpleClassName[container.toString()] / SimpleClassName[Container is null] Do you think that the simple class name is sufficient? I was used to #getInfo() previously which has the FQCN, and this method is gone. Consider that people might copy Tomcat's standard component into their source tree, modify code and package but leave class name as-is. Still, this is good compromise. > If we make more use of the Contained interface, it should be possible to do > this as a single utility method e.g.: > o.a.c.util.DebugUtil.containedToString(Contained) > > Maybe > o.a.c.util.DebugUtil.containedToString(Object, Container) > as well for those objects that don't/can't implement Contained. This make defitively sense! > Which means we might not need to expand the use of Contained anyway. I need > to spend some time thinking about how much sense that does or doesn't make. I have noticed that a lot of components which use Container do not implement Contained at all. Is there a legacy reason for that? It seems awkward. It might be worth considering deprecating RealmBase#getName() since only toString() uses it and it is likely to be superseded. Moreover, toString() has to be well crafted if it is used in MBeans/JMX or log statements to clearly identify the component itself and its location in the server tree. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
