On 9/25/15 8:09 AM, Gilles wrote: > On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote: >> On 9/25/15 7:03 AM, Gilles wrote: >>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote: >>>> Hi Ole, >>>> >>>> for a start, I think you are asking the wrong question. >>>> First of all we need to agree that we want to add some kind of >>>> logging >>>> facility to CM. >>>> If the outcome is positive, there are a handful of alternatives, >>>> some of >>>> them more viable than slf4j in the context of CM (e.g. JUL or >>>> commons-logging). >>> >>> Could someone summarize why those alternatives were deemed "more >>> viable"? >>> >>>> btw. the same discussion has been done for other commons >>>> components as >>>> well, and the result usually was: do not add logging >>> >>> What was the rationale? >> >> Look at the archives. We have discussed this multiple times in the >> past in [math] and each time came to the conclusion that Thomas >> succinctly states above. What has changed now? > > We also discussed several times to stick with Java 5. > Fortunately, that has changed. [Although sticking with Java 7 is > still > a bad decision IMHO.] > > As for logging, IIRC, the sole argument was "no dependency" because > (IIRC) of the potential "JAR hell". > > If there are now well-formed answers proving that the fear was > unfounded, that is also a change. > > IMO, logging is quite important for any "non-obvious" code.[1] > [I'm again stating that, in that respect, CM is not like the other > "Commmons" components.]
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. > > 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. 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, 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. > 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). > > 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
