On 06/03/2014 07:46, Bolz, Michael wrote:
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¹.
You are right: I haven't considered that Olingo provides more a server
framework (as it does client-side BTW) than a "finished" server.
Better adding SLF4J logging API in commons, for usage client and server
side, with no concrete logging implementation.
Regards.
On 05/03/14 15:04, "Francesco Chicchiriccò" <ilgro...@apache.org> 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/
