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 Tue, 14 Jun 2005 11:20:33 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-14 13:20 -------
Re the InvocationTargetException for LogKitLogger:

Does it actually matter whether ExceptionInInitializerError or
InvocationTargetException occurs for LogKitLogger? It does for logadapters that
are part of auto-discovery as we want to continue discovery in the former case
but not the latter. But LogKitLogger is not part of auto-discovery, and
obviously no out-of-tree logger will be. So the only way LogFactoryImpl will
ever try these loggers is when specificLogClassName != null - but in that case,
we throw an LCE regardless of whether ExceptionInInitializerError or
InvocationTargetException occurred, yes?

And all the auto-discovered loggers should now be working as expected. So I
think (hope) things are ok as they are..

Re comment #33 point 3:

Yep, I pretty much agree with your analysis. However there is another option:
just choose not to support this, and make the users fix their problem properly.
Most of the problems reported against JCL are by users who are trying to use JCL
"out of the box" and are confused it doesn't work. And I sympathise with them -
they don't *want* to use JCL, it just came with a library and they just want it
to shut up and not interfere with them running their app.

I think people who are explicitly specifying logadapters via
commons-logging.properties files are generally likely to be able to fix their
classpath problems. And the next release of JCL should include a separate
adapters-only jar which is the *correct* solution to this problem.

So I'm inclined to just ignore this problem. People who specify a log class will
be no worse off than JCL 1.0.4 if they throw commons-logging.jar in their
webapp, and won't have any problems at all if they use
commons-logging-adapters.jar (or whatever we choose to call it).


Comments?

NB: I think it would be a good idea to wind up this bugzilla entry sometime
soon. It's getting rather clumsy to read/navigate. We could start another entry
for the next topic - or just move to the mailing list until we need to start
attaching new patches.

PS: thanks a lot for your comments/discussion of logging. It's really making me
think :-). For such a small project this really is quite difficult isn't it?!

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