Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <00dd01c01e59$5bf50200$be022397@ARES>
Reply-To: "Nicola Ken Barozzi" <nicolaken@supereva.it>
From: "Nicola Ken Barozzi" <nicolaken@supereva.it>
To: <cocoon-dev@xml.apache.org>
References: <20000914.6504900@sahuc-s.imediation.com>
 <39C0D318.9BD4F10F@apache.org>
Subject: Re: avalon.ComponentNotAccessibleException
Date: Thu, 14 Sep 2000 16:34:23 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Stefano Mazzocchi" <stefano@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, September 14, 2000 3:31 PM
Subject: Re: avalon.ComponentNotAccessibleException


> Sebastien Sahuc wrote:
> > 
> > I got the EXACT same problem by using Tomcat 3.3dev anf putting all
> > cocoon jar in web-inf/lib.
> 
> yes, Pier and I are currently chasing this down, stay tuned for news.
> 
> > Didn't try by setting a global classpath, I switched back to resin !
> 
> If you place everything in the system classpath it works, but this is
> NOT what we want: we want classpath-free installation. Drop the
> Cocoon.war and you're done. Period. Nothing more. Nada. Zip.
>  
> > It seems at least that the error message isn't explicit enough. There
> > should be somehow a short explanation on which compoenent it failed to
> > load instead of a [null, null]... :-)
> 
> I feel bad to say this... but Ricardo's way of catching exception is a
> total nightmare... I need to go thru all of C2 code to create a solid
> exception handling framework... we can't continue to catch exception and
> rethrow them encapsulated , this is plain silly.

Stefano, if you say -go- I will try to mend these problems.
A simple way is that whoever throws an error is invited to
throw one that implements the Notifiable interface, which has
the capability of extended explanations.
A notification logger with levels (warning, debug, etc) like the
C1 logger is needed to work in conjunction with notifications.

Anyway I guess you have in mind a more generic error-handling
framework... but Java ha its own, and it works well, IMHO.

If you catch errors only to rethrow them, you have a design problem.
But errors should be more documented: if errors have to be encapsulated
to be sent it's not bad at all, as long as you do it in a class that needs
a description to get going.

In practice, we need a sort on SAX Wrapper interface that accepts
NotificableExceptions instead of SAX Exceptions.
But this is a big mess, I think.

So _final proposal_ (I) make a SAXNotifiableException that implements
Notifiable. When you rethrow you add info, and you can throw it
as a SAXException, no need to change interfaces.
Just have to check in Notifier if it's also instanceOf Notifiable.
BTW, if logging is added, shouldn't error handling become a component?

nicola_ken

Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)