On 25 September 2015 at 16:47, Gilles <gil...@harfang.homelinux.org> wrote:
> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote: > >> On Fri, Sep 25, 2015 at 5:09 PM, Gilles <gil...@harfang.homelinux.org> >> 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". >>> >>> >> that's not correct. The decision to not include any dependencies has >> nothing to do with "JAR hell". >> > > Although I can't find it now, I'm pretty sure that I more than once > got such an answer. > > In order to prevent JAR hell, commons components strictly stick to the >> "Versioning guidelines" [1] >> > > I can't see how it relates. > But if you mean that no JAR hell can emerge from using a logging framework, > then that's good news. > > The no-dependency rule is more related to the proposal of the component, >> see [2] >> > > Thanks for the reminder; in that document, we read: > > (1) Scope of the Package > [...] > 5. Limited dependencies. No external dependencies beyond Commons > components and the JDK > > So we are fine if use "Log4j 2" as kindly offered by Gary. > > My long-standing mentioning of slf4j was only because of its > "weightlessness" (thanks to the no-op implementation of its API). > If "Log4j 2" has followed this path, good for everyone. > > No objection, then? I'm still not clear what log4j 2 adds -- most Apache java projects seem to use log4j 1.2, seems to work well. -- H > > > > Gilles > > > [1] http://commons.apache.org/releases/versioning.html >> [2] http://commons.apache.org/proper/commons-math/proposal.html >> >> Thomas >> >> >> 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.] >>> >>> 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 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 > > -- OpenPGP: https://hasan.d8u.us/gpg.key Sent from my mobile device Envoyé de mon portable
