commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <bes_commons_...@yahoo.com>
Subject Re: DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl
Date Wed, 15 Jun 2005 06:31:29 GMT
... shifting discussion to dev list from bugzilla
entry
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?

Depends on how we resolve the issue of whether to ever
fall into discovery if a relevant ALLOW...PROPERTY was
set.  In the case of InvocationTargetException,
ALLOW_FLAWED_DISCOVERY_PROPERTY would come into play.

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

Even if we decide _not_ to ever fall into discovery,
its mildly tempting to patch LogKitLogger so it fails
with the ExceptionInInitializerError.  Just so if some
poor guys three years from now change something, the
bug won't suddenly pop out.

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

What you're saying makes a lot of sense.  But right
now  my tired brain is refusing to focus, so......

<snip>
> 
> 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?!

It's really quite amazing.  I kind of drifted into
this, but the intellectual challenge of kind of got me
hooked.  Thanks much for putting so much effort into
this, it's making it quite enjoyable and I think the
end result will be worth it.

Brian


		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


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