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 16:47:27 GMT
2011/12/31 Eric Charles <eric@apache.org>:
> A Logger is a logger.

I agree, but then I would say that most times we abuse "loggers" :-)

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

Apple vs Oranges or better Aspects vs Pattern. Why can't you implement
the Logging aspect of a given actor using a Monitor pattern?
I find that if you use a monitor instead of plain "local logging" you
also think better to the meaning of what you want to log and to the
target of the log (user? developer? bug hunter?).
Also a monitor can help during unit tests, instead "standard logging"
doesn't help at all.

> mmh, for me everything is a library and a library needs logging.

I don't agree.
A book is a sorted collection of pages but if you take a bunch of
random pages and add a number to it you can do something that looks
like a book but I wouldn't call "a book".

So a library is a very specific subset of a "bunch of classes".
We could also create 2 distinct worlds of libraries: libraries using
IO and libraries not using IO.

> An application is just a composition of libraries.

An application is another subset of a "bunch of classes", using IO,
and providing a "main" function. You don't need composition to create
an application, instead you need a "main" to do that!
I can't really call every application "a library".
Every subset needs special consideration, so I'm not ready to find a
"one fit them all" solution.

(I'm not saying that mine explanation of words is better than your,
just explaining how I used words, when I used them)

> If I follow your reasoning, nor protocols nor server would need logging?

In my language, server is an application and needs logging. protocols
is a library and should better use monitoring instead of logging. If
server wants to log something happening in protocols then can simply
monitor the procotols and log monitored things.

> Also, logging can be configured with appenders to log in database, jms
> queues... and even in mails (for error level for example) :)

Sure, but it is not really easy to add "monitorability" ta library
that makes use of logging.
Instead is easy to add "logging" to a library that use a monitor pattern.

So if we use a monitor like pattern (a dependency inject Logger
interface , despite the name, is an implementation of a monitor) we
allow users to define what to do.

I love the approach of pico-container loggin (unfortunately I guess it
is a dead project). I find this page really influenced my thought:

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

You would end up with a "catch-all" module where you put everything
that is used by at least 2 modules.
After few years using this approach you will have a 2MB catch-all
library and your protocol library will depend on "james-catchall", a
2MB jar from which we only use 2 logging classes.


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

View raw message