commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 14155] - Access to underlying native logging provider missing
Date Fri, 01 Nov 2002 19:41:12 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14155>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14155

Access to underlying native logging provider missing





------- Additional Comments From craig.mcclanahan@sun.com  2002-11-01 19:41 -------
> On a different level, is there a specific reason not to give access to the 
> native logging provider through the commons implementation? 

My concern is four-fold:

* It violates the layering that is implicit in the facade
  design pattern, and ultimately ties your application logic to
  an underlying native implementation -- the whole thing that
  commons-logging was designed to protect you against.  If you're
  going to do that, you might as well program to the native
  logging interfaces directly.

* There might not be any such thing as a "native logging provider",
  especially for apps that simply provide their own app-specific
  implementation that happens to be programmed to the c-l APIs.

* There might be more than one "native logging provider" if the
  Log instance is doing dispatching or routing to multiple underlying
  logging environments.  There's no obvious way to decide which one
  should be returned.

* There might be different "native logging provider" instances at
  different times -- for example, an implementation of Log in a
  "high availability" environment might support transparently creating
  a new native logging provider instance if it ran into problems
  logging to the old one for some reason.
 
I don't really like the fact that getLogger() exists on Jdk14Logger, but it's
there now.  I suppose I wouldn't mind if we implemented something like
getCategory() on the corresponding Log4J implementation class.  But I really
don't think this belongs on the general o.a.c.l.Log interface.

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message