On 31/12/11 17:47, Stefano Bagnara wrote:
2011/12/31 Eric Charles<[email protected]>:
A Logger is a logger.
I agree, but then I would say that most times we abuse "loggers" :-)
sometimes we abuse, and often we are quite happy to have them.
How many times don't we ask our users to raise the debug level from info
to debug :)
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.
We can indeed extend the discussion and see how we could better
architecture/design our logging functions.
"Better Java Development with AspectJ" (I think the ppt is no more
online) from PARC clearly points the logging as a perfect candidate to
aspect programming.
I didn't remind the Monitor pattern, so I took back my books and found
in the "Pattern oriented software architecture" a Monitor Object pattern
to "synchronize method execution".
So to design such an architecture we could also take into consideration
aspect programing, and be sure that a Monitor will not be confusing with
the 'object monitor' responsible to manage the locks. btw Monitor is
also used in JMX world, and in that way it could have more sense.
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.
A bunch of classes that can be reused in one than one use case.
Why distinguish IO vs non-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)
So an application is a library with a class with a main :) (just kidding)
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:
http://svn.codehaus.org/picocontainer/java/2.x/trunk/logging/src/site/content/monitor-pattern.html
Seems like pico container has/had much to give.
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.
I don't push for james-common atm, but what could be there is just what
developers decide to put. Good or bad design/content is applicable for
any library, not only a potential james-common.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
