james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: Logging library in our projects
Date Sat, 31 Dec 2011 15:21:45 GMT
Like I said, optional dependency works quite well with osgi. We did the same in netty.

Bye
Norman

Sent from my iPhone. Excuse any typos....

Am 31.12.2011 um 15:52 schrieb Stefano Bagnara <apache@bago.org>:

> 2011/12/31 Eric Charles <eric@apache.org>:
>> On 31/12/11 15:03, Stefano Bagnara wrote:
>>>> 
>>>> but didn't know where to go..., this is the reason for this thread :)
>>>> Maybe you have a third option in mind such as having two completely
>>>> separated logging mechanism when running protocols in server?
>>> 
>>> 
>>> IMO we should go with #1 (using a private Logger interface and then
>>> use an adapter to slf4j).
>>> 
>> 
>> Hi Stefano,
>> I am more in favor of #2 to keep things simple.
>> For which reason do you prefer #1?
> 
> Because as a user or a library I prefer to write an adapter (5
> minutes) instead of being forced to use a given logging toolkit.
> 
> History clearly shown us that choosing a logging framework is never a
> good idea: just count how many products moved from one logger to
> another in the last 10 years. I bet 90% had to do that! So if a couple
> of interfaces allow us to encapsulate logging I think it is much
> better.
> 
> Also, encapsulating it for a library gives one more opportunity as it
> allows the library user to intercept/monitor/alter the log calls.
> The best thing would be to name the specific logger interface
> something like "Monitor" (and not Logger) and use domain specific
> calls that will be converted to log calls only by the wrapper.
> 
> We did this in mime4j and it worked fine (it even allowed us to
> introduce new features using the "monitor" in a special way to deal
> with strict/lenient parsing)!
> 
> So, IMO, the "best practice" is that libraries should not provide
> logging at all. Logging is needed by applications (and not libraries)
> because the application user is an human and can't interface
> differently, instead library users are applications (or other
> libraries) so they can communicate much better than using a log file.
> 
>>> I also think that an slf4j adapter could be provided direclty in the
>>> protocols project and used as an optional dependency (so you don't
>>> have to write the adapter in every project).
>>> The "right" approach would be to have a protocols module with the
>>> slf4j adapter, but IMO a module for a single class is too much, so
>>> maybe we can simply put the adapter in the netty module or in the api
>>> module and then declare the slf4j dependency as optional, so that
>>> users of the library will decide if they want to use the slf4j logger
>>> or instead provide their own implementation.
>>> 
>> 
>> Yes, it would be crazy to ask to all our library users to reimplement that
>> adapter.
>> 
>> To open the discussion more, I already saw (don't remember which ones) needs
>> for a "james-common" that could be useful to all our projects. Some logging,
>> streaming,... classes could perfectly fit there.
> 
> I don't like the james-common solution as it would be one more
> dependency anyway and it doesn't make sense if it can be reduced by
> just adding 2 classes in each library.
> All of this PITA could have been skipped if only java.util.Logging
> provided an interface or commons-logging provided also an interface
> for the logger factory, but this never happened and I guess it won't
> happen anymore, so we are forced to do that.
> 
>>> I'm not sure if this plays well with OSGi.
>>> 
>> 
>> No idea... but I don't see why it couldn't
> 
> I have limited experience with OSGi but I remember optional
> dependencies created me some issue, but maybe this is because I was
> not skilled enough to deal with that... so I hope someone else
> (Norman) will answer this doubt.
> 
> Stefano
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message