Re: [logging] LogFactoryImpl weaknesses [WAS Re: [logging] issues highlighted by analysis]

[Brian Stansberry <be...@yahoo.com>]

--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
<snip>

> On Sun, 2005-04-24 at 23:59 -0700, Brian Stansberry
> wrote:
> > I think a better approach would be more like the
> > following:
> > 
> > 1) newInstance checks if logConstructor is null.
> > 2) if null, call a "private Log
> > discoverLogImplementation(String logName)" method,
> > passing the category name of the log.
> > 3) discoverLogImplementation not only tries to
> find
> > the  class and c'tor, it actually instantiates the
> log
> > and returns it.  By doing this it can ensure that
> > discovery actually works, including taking steps
> like
> > the ones you recommend above.
> > 4) If discoverLogImplementation succeeds in
> > instantiating a Log, it sets instance variable
> > logConstructor so in the future the newInstance
> method
> > can instantiate logs directly.
> 
> that sounds like a good plan. one thing to remember
> is that there is
> quite a lot of code in the various instantiation
> methods that has been
> added to cater for unusual environments over time.
> therefore modifying
> the control flow sounds like the right approach.
>

Thanks for the heads up.  After rearranging the contol
flow, some of the existing checks *appear*
unnecessary, but I need to be careful about
subtleties.

> > I roughed out an implementation along these lines
> > tonight and got no exceptions on your
> demonstration
> > tests.  JCL worked as expected in all except 13,
> 14,
> > 18, 20, 26, 28, 30 and 32.  I think it was right
> in 13
> > and 14 as well, and am hoping there is a problem
> in
> > the test fixture on the others.
> 
> that's possible. (i'll discuss this in another
> thread.)
>

Not a test fixture problem; more of a test user
problem .  Once the test user was adjusted, JCL worked
as expected in all tests.
  
> once you're happy to left other people take a look
> at your code, add it
> to a bug report. 

I'll try to do that tomorrow or at most Wed.  I won't
be shy about posting early and having people find a
few warts; I figure letting more eyes look at the
subtleties is more important.

Brian

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

Re: [logging] LogFactoryImpl weaknesses [WAS Re: [logging] issues highlighted by analysis]

[robert burrell donkin <rd...@apache.org>]

On Mon, 2005-04-25 at 23:22 -0700, Brian Stansberry wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
> <snip>
  
> > once you're happy to left other people take a look
> > at your code, add it
> > to a bug report. 
> 
> I'll try to do that tomorrow or at most Wed.  I won't
> be shy about posting early and having people find a
> few warts; I figure letting more eyes look at the
> subtleties is more important.

+1

we'll need to go through the code in detail. 

my tentative plan is to create a branch (lovely, easy, cheap SVN
branches :) and patch in your code pretty quickly and then everyone can
spend time analysing it. opinions?

- robert


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