I agree with ³slf4j² as logging API and declaring the dependency in the common module.
Currently in the v2 core and api there is no concrete logging backend referenced. Their it is the same way as Francesco propose for the client side. When the core/api are used e.g. in a (web) application like in the reference scenario the application decides which logging backend is used. Then this has only to be compatible to slf4j¹. Kind regards, Michael On 05/03/14 15:04, "Francesco Chicchiriccò" <[email protected]> wrote: >On 05/03/2014 15:02, Klevenz, Stephan wrote: >> Hi, >> >> I've seen that client code is using >>org.slf4j:slf4j-api:jar:1.7.5:compile >> >> I would like that for server side, too. => move dependency to commons. >> Main reason is to log errors only at rare places. Tracing the happy >>path should be avoided not to pollute trace files and decrease >>performance. >> >> WDYT? > >+1 > >On server side I would also add a concrete SLF4J backend (logback? >log4j2?), while on client side I would only keep the api dependency, to >let the final client application decide which actual logging framework >has to be used. > >Regards. > >-- >Francesco Chicchiriccò > >Tirasa - Open Source Excellence >http://www.tirasa.net/ > >Involved at The Apache Software Foundation: >member, Syncope PMC chair, Cocoon PMC, Olingo PPMC >http://people.apache.org/~ilgrosso/ >
smime.p7s
Description: S/MIME cryptographic signature
