On Fri, Sep 25, 2015 at 8:50 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 9/25/15 8:45 AM, Ole Ersoy wrote: > > Hi Thomas, > > > > On 09/25/2015 08:54 AM, 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. > > Well it has to be SLF4J because that's the one I'm most familiar > > with :). We did discuss having observers that can listen in on > > increment events that algorithms publish. This would provide a > > dependency free method for doing so with one drawback. Now > > everyone that wants the algorithm to log has to implement logging. > > This is the right approach, IMO, for reasons that have been stated > in the archives. Has more as much to do with separation of concerns > and clean API contracts as dependencies and conflicts. > Note that Log4j 2 (we just released 2.4) has a clean separation between logging API and implementations, including it's own of course. We are also an active group of developers here to help you should you it! :-) https://logging.apache.org/log4j/2.x/index.html Gary > > Phil > > > >> 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). > > Would you be upset if it was SLF4J? This is minor, but I like the > > @SLF4J annotation that Lombok provides. > > > >> > >> btw. the same discussion has been done for other commons > >> components as > >> well, and the result usually was: do not add logging > > I think for the reason that commons should not introduce > > transitive dependencies? This has been solved fairly well (Below). > > > > Cheers, > > - Ole > > > >> > >> 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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
