On 09/25/2015 11:34 AM, Phil Steitz wrote:
I disagree. Good tests, API contracts, exception management and documentation
can and should eliminate the need for cluttering low-level library code with
debug logging.
Logging could be viewed as clutter. Constructed the right way, the logging
statements could also be viewed as comments.
I agree that good tests, API contracts, and in general keeping the design as
minimalistic and simple as possible should be the first criteria to review
before introducing logging. When the code is trivial I leave logging out,
unless I need to put in a few statements in order to track collaboration
between components in an algorithm. Other times the method is as simple as it
gets and I have to have logging. For example take the
LevenbergMarquardtOptimizer optimize() method. It's atomic in the sense that
what's in the method belongs in the method. There are several loops within the
main loop, etc. and tracking what's going, even with a observer being notified
on each increment, would be far from elegant.
For example perhaps we want to see what's going on with the parameters in this
small (5% of the method size) section of code:
// compute the scaled predicted reduction
// and the scaled directional derivative
for (int j = 0; j < solvedCols; ++j) {
int pj = permutation[j];
double dirJ = lmDir[pj];
work1[j] = 0;
for (int i = 0; i <= j; ++i) {
work1[i] += weightedJacobian[i][pj] * dirJ;
}
}
If there is something wrong with this in production, the shortest path to
figuring that out is reviewing a trace. The longer path is to stop the server.
Grab the data. Open up a debugger. Run the data.
If we wanted to observe this section of code the observer would be looking at
sub loops of of the optimize method. So that's doable, but it creates an
interface design for the observer that's cluttered with events corresponding to
various low level algorithm details.
Several times, I've been obliged to create a modified version of CM
to introduce "print" statements (poor man's logging!) in order to
figure out why my code did not do what it was supposed to.
It's pretty tragic that anyone of us should have to do this. It's also
wasteful, because if Gilles has to do this, then there's a good chance that
others have to do it to. The reason Tomcat logs at various levels is so that
we can see what's going on in production and track down bugs. Lets become one
with the logging and make it into something that strengthens both code
integrity and comprehensibility. Everyone take take out your Feng Shui mat and
do some deep breathing right now.
Here again, tests, good design, code inspection are the way to go in
low-level components. I have also spent a lot of time researching
bugs in [math], other Commons components and other complex systems.
My experience is a little different: excessive logging / debug code
for code that contains it often just tends to get in the way,
It's a very good point. Sometimes we come across logging statements that are just noise.
Given how rigorous we are about reviewing everything though, I think a win win would be
to limit the noise during code review, and pledge not to "Call our mom" in the
middle of the code, etc.
especially after it has rotted a bit. Rather than adding more code
to maintain so that you can have less conceptual control over the
functional code, it is better, IMNSHO, to focus on making the
functional code as simple as possible with clean well-documented,
test-validated API contracts.
Totally agree. I think this should be the first priority, and that logging
should be used when there are no simple clean alternatives.
It also makes a code easier to debug while developing or modifying it
(without resorting to poor man's logging, then deleting the "print",
then reinstating them, then deleting them again, ad nauseam).
Pretty sure we have all been here.
Cheers,
- Ole
Gilles
[1] No quality or complexity judgment implied.
Phil
Gilles
Thomas
On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ole.er...@gmail.com>
wrote:
Hello,
We have been discussing various ways to view what's happening
internally
with algorithms, and the topic of including SLF4J has come up.
I know that
this was discussed earlier and it was decided that CM is a low
level
dependency, therefore it should minimize the transitive
dependencies that
it introduces. The Java community has adopted many means of
dealing with
potential logging conflicts, so I'm requesting that we use SLF4J
for
logging.
I know that JBoss introduced its own logging system, and this
made me a
bit nervous about this suggestion, so I looked up strategies for
switching
their logger out with SLF4J:
http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j
The general process I go through when working with many
dependencies that
might use commons-logging instead of SLF4J looks something like
this:
http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi
With JDK9 individual modules can define their own isolated set of
dependencies. At this point the fix should be a permanent. If
someone has
has a very intricate scenario that we have not yet seen, they
could use
(And probably should use) OSGi to isolate dependencies.
WDYT?
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
