You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by "Klevenz, Stephan" <st...@sap.com> on 2014/03/05 15:02:12 UTC
logging
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?
-- Stephan
Re: logging
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò" <il...@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/
Re: logging
Posted by "Bolz, Michael" <mi...@sap.com>.
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ò" <il...@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/
>
Re: logging
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/