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? 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
