james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: Logging library in our projects
Date Sat, 31 Dec 2011 15:18:16 GMT
Hi Stefano, Comments inline.

On 31/12/11 15:52, Stefano Bagnara wrote:
> 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.

Makes sense.

> 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)!

A Logger is a logger.

For monitoring purposes, I would not generalize the Logger to be a 
Monitor. But this is way beyond our discussion on the logging libraries :)

> 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.

mmh, for me everything is a library and a library needs logging. An 
application is just a composition of libraries.
If I follow your reasoning, nor protocols nor server would need logging?
Also, logging can be configured with appenders to log in database, jms 
queues... and even in mails (for error level for example) :)

>>> 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.

2 classes for logging, 3 more classes for something else, that could 
save us some code and maintenance, but yes, it also needs a release, 
that's not piece-of-cake...

> 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.

That may be the price to pay for flexibility.

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

eric | http://about.echarles.net | @echarles

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

View raw message