On Mon, 2004-12-20 at 18:28 +0100, Ceki Gülcü wrote:
> In my last message, I failed to emphasize the brittleness of the
> "break into interfaces" hypothesis. Even if at a high-level of
> abstraction two APIs perform the same task, this does not mean that
> they can be abstracted away by a thin facade (or bridge). For example,
> all the attempts made at bridging X.25 and TCP/IP, both well defined
> and stable protocols, have failed miserably, even if both stacks
> supposedly fit into layers 1-4 of the 7 layer OSI network model.
I quite agree with this.
And I don't think the approach of providing multiple optional interfaces
in commons-logging to support "advanced" features that various logging
libraries implement is useful either. As I've written in previous
emails, I do *not* like the idea of an application failing to start
because an appropriate logging implementation is not present.
I think commons-logging should be a *simple* API that abstracts only the
*basic* functionality of logging. The current API is fine; log strings
at various priority levels to a single named category. Any reasonable
log implementation will be able to provide a sane mapping for these
concepts.
But I don't think it is worth trying to extend JCL much beyond this. As
Ceki says, logging libraries can provide widely varying features and it
is not productive to try to map these to portable APIs.
JCL does a very useful job for jakarta-commons libraries: provide a
means for the commons libraries to implement logging without enforcing a
logging implementation on the larger app which uses the library. Note
that the kind of log messages generated by commons components are of
course implementation-related and are therefore aimed at the *developer*
not the user. For this reason, i18n support is not terribly useful for
commons component logging.
However I'm not convinced that for *applications* (rather than
libraries) it is sensible to use JCL at all; why not just pick a
concrete logging implementation and use that? You get all the necessary
features, and apps can deploy whatever logging implementation they want.
The only awkward situation is container frameworks like J2EE. In this
case, you may want logging to be redirected to the container's logging
implementation so that logging from all apps within the framework is
treated consistently. I can see some kind of common API cabable of
generating i18n messages being useful here.
After all the discussion on logging recently, I'm coming to the
conclusion that Richard's original proposed features (i18n, discovery
changes) should *not* be included in JCL. None of these features help
commons components with their logging requirements, and these features
*are* going to make JCL significantly more complex and controversial. It
would be better to start a separate project. If this project can
successfully resolve the issues then maybe it could be merged back in to
JCL.
To summarize, my (non-binding) votes are:
-1 to adding extra *optional* features to JCL that fail if the
"discovered" logging implementation doesn't suport them. This
includes Richard's EnterpriseLog class, and Matt Scarlata's
proposals too.
-1 to *mandatory* configuration for JCL
+1 to keeping JCL as a least-common-denominator logging API that
can be used for commons components.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
