james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Logging library in our projects
Date Sat, 31 Dec 2011 14:52:59 GMT
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

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.


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

View raw message