Hi Stefano, Comments inline.
Eric
On 31/12/11 15:52, Stefano Bagnara wrote:
2011/12/31 Eric Charles<e...@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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
