On 10 June 2016 at 13:39, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
>> On Jun 10, 2016, at 3:34 AM, Torsten Curdt <tcu...@vafer.org> wrote:
>>
>> On Fri, Jun 10, 2016 at 12:14 PM, sebb <seb...@gmail.com> wrote:
>>
>>> On 10 June 2016 at 10:46, Gilles <gil...@harfang.homelinux.org> wrote:
>>>> Hi.
>>>>
>>>> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
>>>>>
>>>>> FWIW
>>>>>
>>>>> I am not a fan of libraries and frameworks just logging away anyway.
>>>>>
>>>>> What I usually do this days:
>>>>> Have an interface in the library itself. Along the lines of
>>>>>
>>>>> public interface Console {
>>>>> void debug( String message );
>>>>> }
>>>>
>>>>
>>>> What you do here (simple usage) is the same as what "slf4j-api" or
>>>> "log4j2-api" do.
>>>
>>> Not really, because you also need a run-time implementation.
>>> That's two extra jars, regardless of whether any output is needed.
>>>
>>> And the user has to provide a configuration file (at least with log4j)
>>>
>>
>> Exactly. It's so simple and it doesn't introduce any deps.
>> Whether that's goal one can align with is another matter.
>> But it means no logging framework discussions anymore ;)
>
> The disadvantage of this approach is that you loose the location information
> - every log event will come from your debug method instead of the code
> actually doing the logging.
Depends on what the implementation does.
For example:
@Override
void debug( String message ){
new Throwable(message).printStackTrace();
}
> Ralph
>
>
>
> ---------------------------------------------------------------------
> 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
