DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl

Bugzilla from bugzilla@apache.org
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 [hidden email]  2005-05-31 07:49 -------
I still don't understand that bit with the else around the log4j discovery.

If someone has specified an explicit logclass, ie
  if (specifiedLogClassName != null)
is true then surely:
 * we create an instance of the specified class and return it, or
 * we fail with an exception

I don't think we should *ever* fall back to discovery mode if
specifiedLogClassName is not null. So I would write this:

if (specifiedLogClassName != null) {
  try {
    // note: createLogClass never returns null..
    result = createLogClass(...);
    return result;
  } catch(LogConfigurationException ex) {
    // this type of exception means we've alread output diagnostics
    // about this issue, etc.; just pass it on
    throw ex;
  } catch(Throwable t) {
    // log problem, and potentially throw an exception if the user
    // doesn't want recovery from flawed discovery
    handleFlawedDiscovery(..);

    // even if configuration info states that we should recover from
    // flawed logging classes, we *never* recover from a flawed log
    // which was explicitly specified by the user...
    throw new LogConfigurationException(t);
  }

  // this if-statement never exits!
}

// test for log4j
try {
   result = .....

--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl

Brian Stansberry
<snip>
from:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34661

> ------- Additional Comments From
> [hidden email]  2005-05-31 07:49 -------
> I still don't understand that bit with the else
> around the log4j discovery.
>
> If someone has specified an explicit logclass, ie
>   if (specifiedLogClassName != null)
> is true then surely:
>  * we create an instance of the specified class and
> return it, or
>  * we fail with an exception
>
> I don't think we should *ever* fall back to
> discovery mode if
> specifiedLogClassName is not null.

I agree with this philosophy but wanted to point out
that if a user both:

1) configures a Log class using a property, and
2) uses a property to configure JLC NOT to fail on an
error

throwing an exception will contravene #2.

I don't have a problem with this, it just means the
explanation of the usage of the "FailOnException"
configuration property gets a bit more complicated.

BTW, it would be somewhat strange for a user to
configure the "FailOnException" property to false,
since that is its default value anyway.

I'm raising this point now because in the next day or
two I'll create the next patch, the one that adds the
configuration ability.  If anyone has any opinions on
this point (Robert??) please let me know.

Best,
Brian


               
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl

Simon Kitching
On Wed, 2005-06-01 at 23:12 -0700, Brian Stansberry wrote:

> <snip>
> from:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34661
>
> > ------- Additional Comments From
> > [hidden email]  2005-05-31 07:49 -------
> > I still don't understand that bit with the else
> > around the log4j discovery.
> >
> > If someone has specified an explicit logclass, ie
> >   if (specifiedLogClassName != null)
> > is true then surely:
> >  * we create an instance of the specified class and
> > return it, or
> >  * we fail with an exception
> >
> > I don't think we should *ever* fall back to
> > discovery mode if
> > specifiedLogClassName is not null.
>
> I agree with this philosophy but wanted to point out
> that if a user both:
>
> 1) configures a Log class using a property, and
> 2) uses a property to configure JLC NOT to fail on an
> error
>
> throwing an exception will contravene #2.
>
> I don't have a problem with this, it just means the
> explanation of the usage of the "FailOnException"
> configuration property gets a bit more complicated.

We could call this property "FailOnDiscoveryException" instead.

By the way, I'm intending to make a few tweaks to the existing
LogFactoryImpl code in the next few hours. So please don't forget to svn
update before starting your work on this patch!

Regards,

Simon




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]