Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
From: <david.gray@hic.gov.au>
Subject: LogKit: Proposal to allow better Error Handling when using JMS and
 JDBC.
To: <avalon-dev@jakarta.apache.org>
Message-ID: <OF97D39598.A5A78223-ON4A256BA3.002847E4@hicnet>
Date: Mon, 22 Apr 2002 17:34:34 +1000
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


I have considered how to implement the ability to provide an error handler
prior to trying to open a JMS/JDBC connection. The problem originally
manifested itself as a NPE when the program was unable to connect to JMS.
The current code in CVS only uses the DefaultErrorHandler which reports
the message but does not advise the program via exceptions. Here is my
proposal
to create a mechamism by which the application can implement an error
handler
so that it knows of the failure:


Add a series of new constructors to the class hierarchy from AbstractTarget
to JMSQueueTarget (and possibly NormalizedJDBCTarget) to include an
Errorhandler
parameter.

For example, the new JMSQueueTarget constructor looks like this:

    public JMSQueueTarget( final MessageBuilder builder,
                           final QueueConnectionFactory factory,
                           final Queue queue,
                           final ErrorHandler handler )
    {
        super( builder, handler );
        m_factory = factory;
        m_queue = queue;
        open();
    }
and the new AbstractJMSTarget looks like this:

    public AbstractJMSTarget( final MessageBuilder builder, final
ErrorHandler errorHandler)
    {
        super(errorHandler);
          m_builder = builder;
    }

I had to add 2 constructors to AbstractTarget which look like this:


public AbstractTarget() {

}

and

public AbstractTarget(final ErrorHandler errorHandler) {
      if (errorHandler != null) {
            m_errorHandler = errorHandler;
      }
}

I had thought about hooking the nil parameter constructor to the 2nd by
doing this(DEFAULT_ERRORHANDLER)
but thought this was really not required.

Now if this looks reasonable I am happy to contribute the class files
(after suitable testing) for the above
and I may think about similar changes for the JDBC targets. Apart from
testing the JMS stuff the fact that
the AbstractTarget has change may require testing of other concrete
classes.

Any comments on the design?

ANOTHER POSSIBLE CHANGE
=======================

The next change I see is that I would also like to add this facility into
excalibur.logger.factory classes. This could take the form of the XML
specifying the name of the class that implements the ErrorHandler and then
using a class loader to instantiate the class. I have previously used the
Class.forName method in combination with the instanceOf operation to do
this but that uses the default classLoader. ClassLoaders are not something
that I know that much about just enough to get by.

Any comments on this proposal?


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