avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <david.g...@hic.gov.au>
Subject RE: ConsoleLogger inside AbstractLogEnabled (AbstractLoggable)
Date Thu, 04 Apr 2002 00:59:39 GMT

This problem is related to one I noted in the JMSQueueTarget (refer
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06593.html and
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg07082.html and
for the thread.

I suspect that the JDBC target and a few others suffer the same problem if
the constructor fails. If the constructor fails the error handler is null
and the poor client has not had any chance to set it to something.

I was able to reproduce the error by stopping the underlying JMS client (in
this case MQ) but the problem can arise if the userID and password is

While Pete has added a fix to ensure that the pointer is not null, it just
uses a singleton DefaultErrorHandler which merely logs the message to the
console and then continues without telling the client application. What is
needed is the ability to OPTIONALLY specify the error handler on the
constructor call for all targets or lazy initialize the call to open JMS,
JDBC etc until the error handler is set. Implies a parallel set of
constructors which I have thought about coding - just lack the time at work
and time at home - even scarcer.

As an allied change, the org.apache.avalon.excalibur.logger.factory may
also need changes to allow the ability to specify an Errorhandler .

Then the choice of constructor really depends on the requirements of the
project. For example, my project rqeuires that the client knows about the

"Berin Loritsch" <bloritsch@apache.org> on 03/04/2002 02:24:11

Please respond to "Avalon Developers List" <avalon-dev@jakarta.apache.org>

To:    "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>

Subject:    RE: ConsoleLogger inside AbstractLogEnabled (AbstractLoggable)

> -----Original Message-----
> From: Bachran, Michael [mailto:MBachran@onebridge.de]
> Sent: Monday, March 18, 2002 7:54 AM
> To: Avalon-Dev (E-mail)
> Subject: ConsoleLogger inside AbstractLogEnabled (AbstractLoggable)
> Hi,
> I got a question on the ConsoleLogger. When sometimes someone
> forgets to set/enable the logging in a component you have to
> spend some time finding a NPE or getLogger() returning null
> might even affect the runtime behaviour (hopefully only
> during testing :-)). So my question is what you think about
> initializing the logger member inside AbstractLogEnabled
> (AbstractLoggable) with a ConsoleLogger so that getLogger()
> should never return null?

Honestly, we should throw a LoggerNotSetException() or something
useful like that.  If you return a NullLogger (swallows all log
events) or a ConsoleLogger (slows everything down by forwarding
events to the screen), you never report a bug to the user.

Furthermore, you are not guaranteed access to the System.out stream.

The LoggerNotSetException approach is cleaner--and forces the
developer to write correct code.  It also gives the developer
a clue as to what the real problem is.

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

NOTICE - This message is intended only for the use of the 
addressee named above and may contain privileged and 
confidential information.  If you are not the intended recipient
of this message you are hereby notified that you must not 
disseminate, copy or take any action based upon it.  If you 
received this message in error please notify HIC immediately.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of HIC.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message