cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: avalon.ComponentNotAccessibleException
Date Thu, 14 Sep 2000 14:34:23 GMT
----- Original Message ----- 
From: "Stefano Mazzocchi" <>
To: <>
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 Barozzi - AISA Industries S.p.A
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)

View raw message