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: [logging] detecting logging libs
Date Mon, 23 May 2005 03:56:25 GMT
--- Simon Kitching <skitching@apache.org> wrote:

> On Sun, 2005-05-22 at 18:38 -0700, Brian Stansberry
> wrote:
> > It's a good point; the "assumed" category names in
> the
> > various isXYZAvailable method is my biggest
> dislike
> > about the patch I submitted.  Actually, if an
> approach
> > like the patch were adopted, I think we should
> > consider marking those methods as deprecated
> (they're
> > not used in the patched LogFactoryImpl itself) and
> > dropping them at the next release with a point
> scope
> > that allows it.
> 
> Ah - I see. With your approach, you just pass the
> name that the user
> provided, so don't need a dummy category name at
> all. Fine.
> 
> Regarding deprecation, if we're going to change the
> logic flow within
> the LogFactoryImpl such that the existing
> isXYZAvailable methods are no
> longer called, then to me that's *just as much* an
> incompatible change
> as removing the methods. 
> 
> Removing the methods potentially causes subclasses
> to not compile/link,
> but leaving them there and not calling them causes
> subclasses to
> *logically* fail, which in my view is even worse
> because it's not
> visible.
> 

+1

I'd tended to think about this in terms of a subclass
writing its own logic flow but calling into the
various isXYZAvailable methods, but you're right, a
subclass could also count on the superclass logic flow
but override an isXYZAvailable.  This is more likely
even.

> I'd be happy with including this approach in the
> next release, removing
> the redundant isXYZAvailable methods and calling the
> next release 1.1.
> In practice, I'm sure no-one *does* subclass
> LogFactoryImpl so there's
> no problem.  In fact I'd be happier with this than a
> 1.0.5 where the
> methods exist but don't do anything.
>

+1

A major refactor of the core class in the library
seems a bit much for two-decima point release name.
 
> > 
> > In general, if any significant work on
> LogFactoryImpl
> > is done I think a review of its API would be good.
> 
> > This seems to me to be the kind of class that if
> > someone wants a different implementation, they
> should
> > write a different implementation and not count on
> a
> > lot  of behaviors exposed by a superclass.
> 
> I'm working on a major refactoring proposal now,
> that will not just
> review but gut LogFactoryImpl :-).
> 
> > 
> > Looking into it more, I remembered that
> > LogFactoryImpl.getInstance(Class clazz) just calls
> > getInstance(clazz.getName()) and thus already
> creates
> > a requirement that Log implementations support
> fully
> > qualified class names.  So any adapter that
> doesn't do
> > this must be designed to work with a custom
> > LogFactory.  So, the potential list of users
> affected
> > by this issue is smaller -- only those with custom
> > LogFactory implementations and Log implementations
> > that don't support class names.
> 
> Yes, good point. We should really document that in
> the Log interface. In
> order to be able to swap in/out alternative logging
> implementations,
> there does need to be a "standard" for category
> names that the concrete
> Log classes can all handle. It's implicit in the
> whole concept of JCL
> (well, any logging wrapper).
> 
> 
> > Half-baked idea to throw out before I run.  Add to
> > LogFactoryImpl:
> > 
> > /**
> >  * Returns a category that can be used to test
> whether
> >  * an instance of a <code>Log</code> can be
> created.
> >  * <p>
> >  * This default implementation returns the fully 
> >  * qualified name of this class.  Subclasses
> should
> >  * override this if they support <code>Log</code>
> >  * implementations that cannot handle this
> category.
> >  * </p>
> >  */
> > protected String getTestCategory() {
> >   return getClass().getName();
> > }
> > 
> > All the various isXYZAvailable methods would call
> this
> > method when creating a test instance.
> 
> No need I think. Your code in bugzilla which simply
> uses the first log
> category passed in by the user seems fine to me.
> 

Good.  The above would only be relevant if the unused
isXYZAvailable methods were left in, and you make a
good argument for removing them.

> One minor issue: if the user passes in an "invalid"
> category name of
> some sort, then we might assume that the logging
> implementation is not
> available. Not a likely problem though.
> 
> And as you point out above, JCL effectively imposes
> its own standard on
> what is and is not a valid category name anyway, so
> if the above is
> really considered a problem then we can just declare
> that "" is always a
> valid category name that returns the "root"
> category, and all Log
> subclasses need to handle that category name.
> 
> 
> Hmm.. what about when a logging implementation is
> available, but
> attempting to create a logger fails, eg because the
> underlying
> implementation's config file is bad. If we test for
> the existence of the
> logging lib by creating a logger, then we would fall
> back to other
> logging libs in this case - is that what we want?
>

I think this comes down to the general philisophical
question -- should a logging framework be able to fail
 an application? There's good arguments on both sides
which has got me starting to think about how to make
it a configurable option.  I've got a suspicion it
might be pretty simple.

Best,
Brian

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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