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 34661] - [logging][PATCH] Improvements to LogFactoryImpl
Date Fri, 03 Jun 2005 05:02:12 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34661>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34661





------- Additional Comments From skitching@apache.org  2005-06-03 07:02 -------
(In reply to comment #26)
> 
> 1) This logic should only be invoked in cases of ClassCastException, not 
> InvocationTargetException, etc.

Actually, only when ClassCastException happens when trying to convert to Log..

(2a) This sounds ok to me. The user wanted that logging lib, and they didn't
specify FailOnHierarchyError (or whatever we call it)
(2b) This sounds ok to me. The user didn't want discovery..


On related matters, I would prefer not to take the approach:
 * try context
 * try classloader of the LogFactoryImpl.

I think it would be better to start at the context classloader and walk up the
classloader inheritance tree until reaching the classloader that loaded the
LogFactoryImpl. I've been playing with various ways of achieving this, but it
isn't easy when you also need to treat exceptions as fatal or recoverable along
the way. Opinions?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message