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:11: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 ch@ipin.com  2002-11-01 19:11 -------
If I understand you right, you mean to do something like that:

Log log = LogFactory.getLog("foobar");

Class logProviderClass = log.getClass();
if (logProviderClass instanceof Jdk14Logger) {

   java.util.logging.Logger nativeLogProv = 
     java.util.logging.Logger.getLogger("foobar");

   // do configuration for JDK 1.4 logging API

} else if (logProviderClass instanceof Log4JCategoryLog) {

   org.apache.log4j.Logger nativeLogProv =
     org.apache.log4j.Logger.getLogger("foobar");

   // do configuration for Log4j

}


I believe that could work ok under most circumstances, and is probably 
sufficient on the short-term. However, one issue I can think of where this 
might not work is if the customer has their own native logging provider which 
is not implemented using the singleton pattern. Altogether I think this is a 
good workaround, and I will evaluate it.

On a different level, is there a specific reason not to give access to the 
native logging provider through the commons implementation?

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