You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2001/12/04 18:09:29 UTC
Re: Sitemap error-handling [was : [VOTE] directly setting variables in
sitemap]
Nicola Ken Barozzi a écrit :
>
> ----- Original Message -----
> From: "Nicola Ken Barozzi" <ba...@nicolaken.com>
> To: <co...@xml.apache.org>
> Sent: Tuesday, December 04, 2001 1:34 PM
> Subject: Re: Sitemap error-handling [was : [VOTE] directly setting variables
> in sitemap]
>
> ----- Original Message -----
> From: "Sylvain Wallez" <sy...@anyware-tech.com>
> To: "cocoon-dev" <co...@xml.apache.org>
> Sent: Tuesday, December 04, 2001 10:13 AM
> Subject: Sitemap error-handling [was : [VOTE] directly setting variables in
> sitemap]
>
> >
> > nicolaken@supereva.it a écrit :
> > >
> > <snip/>
> > > >
> > > > Time to introduce an idea I had recently. For now, we only have two
> > > > types of map:handle-errors : 404 (ResourceNotFoundException) and 500
> > > > (all other Exceptions). What about extending this to allow specific
> > > > exception types to trigger specific map:handle-errors ? This would
> allow
> > > > the following constructs :
> > > >
> > > > <map:handle-errors
> > > >
> exception="org.apache.avalon.framework.configuration.ConfigurationError">
> > > > <map:act type="warn-admin-of-bad-config"/>
> > > > <map:transform src="configError2html.xsl"/>
> > > > <map:serialize type="html"/>
> > > > </map:handle-errors>
> > > >
> > > > <map:handle-errors
> > > > exception="java.lang.security.AccessControlException">
> > > > <map:transform src="ace2html.xsl"/>
> > > > <map:serialize status-code="403"/>
> > > > </map:handle-errors>
> > > >
> > > > Thoughts ?
> > > >
> > >
> > > Well, in the xml of the error you have quite a lot on info you can use
> to decide what to do without changing the sitemap.
> > > You could use a special selector that selects on the content of an
> "error namespace" tag to select the appropriate action, or a series of
> transformers like the log transformer (passthrough) that basically does the
> same thing.
> > > I don't see the need of new semantics.
> > >
> > > Nicola Ken Barozzi These are the days of miracle and wonder...
> > > ...so don't cry baby, don't cry
> > > <xm...@nicolaken.com> Paul Simon
> >
> > I'm afraid this won't work : the XML describing the error is only
> > available at pipeline processing time, that is _after_ all selectors,
> > actions and the like have been executed.
>
> Before handle-errors the XML describing the error is not there,
> after you should have another pipeline to spit it out, and if
> this still doesn't work, a generic html error comes out.
> In fact in handle-errors, in the current sitemap, you have a Transformer.
> If in handle-errors isn't a special pipeline where you can act, select,etc
> I think it should become one. This is how it was intended.
You're right : a new pipeline is started in <handle-errors> and you can
add whatever sitemap construct you want but a generator (the special
ErrorNotifier generator is set by the engine).
But you can't do anything in this pipeline that depends on the error
contents : the exception is passed to the ErrorNotifier and isn't
available in any of the match/act/select that you can put in this
pipeline.
> > Also, continuing my proposal, it would be good to be able to specify the
> > error notifier (the special generator for exceptions). For now it is
> > hard-coded to use the Notifier which does a nice job for most
> > exceptions. But we use here some smart exceptions which carry a lot of
> > useful information and are XMLizable, and I'd like to be able to set the
> > generator in handle-errors to process this information.
>
> Sorry, I don't get it.
> The ErrorNotifier checks is an Exception is instanceof Notifiable;
> if so il spits out all extra descriptions using that interface.
Nope : it builds a Notification with the Exception and uses Notifier to
produce XML out of it.
> All exceptions in Cocoon should implement that interface, so
> to be able to provide all the extra stuff you are talking about.
Sorry, but I find Notifiable too constraining in what can be expressed
using it. While this is good if we can't trigger error-handlers by
specific exception types, this will be very limiting if we introduce
this feature.
For a use case, look a my previous post in the thread "[VOTE] directly
setting variables in sitemap" where I talk about ExplainableException
to see what I mean.
Sylvain
> This hasn't been done because when I was starting to ask all to do it and
> "enforce" it by adding to the error the phrase "Extra descriptions are not
> available because the programmer was too lazy to put them in" ;-)
> I had to leave the list. So I guess it's my fault not making this clear
> enough.
> Implementing this interface you don't need to make a Generator to
> show the extra descriptions, and your XML is always the same -> you can
> easily have standard stylesheet for all errors and are guaranteed that the
> error notification gets generated.
>
> PS. I've just taken a look at the c2 src: Notifiable is called Notificable,
> I thought it was changed. I guess it's time I give it another check.
> Anyway, here is the interface; the extra descritions are the point.
> Now that I remember I proposed this stuff to the Avalon guys when they
> were writing the CascadingException stuff and they convinced me that
> it wasn't general enough for a generic exception (too rich)... but I forgot
> to make Notifiable forcibly Cascading...
> ...don't you think a Notification should be cascading?
> Anyway, the original-original idea was to use the error namespace xml
> inline to report xalan warnings and such.
> Suggestions?
>
> public interface Notificable {
>
> /**
> * Gets the Type attribute of the Notificable object
> */
> String getType();
>
> /**
> * Gets the Title attribute of the Notificable object
> */
> String getTitle();
>
> /**
> * Gets the Source attribute of the Notificable object
> */
> String getSource();
>
> /**
> * Gets the Sender attribute of the Notificable object
> */
> String getSender();
>
> /**
> * Gets the Message attribute of the Notificable object
> */
> String getMessage();
>
> /**
> * Gets the Description attribute of the Notificable object
> */
> String getDescription();
>
> /**
> * Gets the ExtraDescriptions attribute of the Notificable object
> */
> HashMap getExtraDescriptions();
> }
>
> Nicola Ken Barozzi These are the days of miracle and wonder...
> ...so don't cry baby, don't cry
> <xm...@nicolaken.com> Paul Simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sitemap error-handling [was : [VOTE] directly setting variables in sitemap]
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Tuesday, December 04, 2001 6:09 PM
Subject: Re: Sitemap error-handling [was : [VOTE] directly setting variables
in sitemap]
>
>
> Nicola Ken Barozzi a écrit :
> >
> > ----- Original Message -----
> > From: "Nicola Ken Barozzi" <ba...@nicolaken.com>
> > To: <co...@xml.apache.org>
> > Sent: Tuesday, December 04, 2001 1:34 PM
> > Subject: Re: Sitemap error-handling [was : [VOTE] directly setting
variables
> > in sitemap]
> >
> > ----- Original Message -----
> > From: "Sylvain Wallez" <sy...@anyware-tech.com>
> > To: "cocoon-dev" <co...@xml.apache.org>
> > Sent: Tuesday, December 04, 2001 10:13 AM
> > Subject: Sitemap error-handling [was : [VOTE] directly setting variables
in
> > sitemap]
> >
> > >
> > > nicolaken@supereva.it a écrit :
> > > >
> > > <snip/>
> > > > >
> > > > > Time to introduce an idea I had recently. For now, we only have
two
> > > > > types of map:handle-errors : 404 (ResourceNotFoundException) and
500
> > > > > (all other Exceptions). What about extending this to allow
specific
> > > > > exception types to trigger specific map:handle-errors ? This would
> > allow
> > > > > the following constructs :
> > > > >
> > > > > <map:handle-errors
> > > > >
> >
exception="org.apache.avalon.framework.configuration.ConfigurationError">
> > > > > <map:act type="warn-admin-of-bad-config"/>
> > > > > <map:transform src="configError2html.xsl"/>
> > > > > <map:serialize type="html"/>
> > > > > </map:handle-errors>
> > > > >
> > > > > <map:handle-errors
> > > > > exception="java.lang.security.AccessControlException">
> > > > > <map:transform src="ace2html.xsl"/>
> > > > > <map:serialize status-code="403"/>
> > > > > </map:handle-errors>
> > > > >
> > > > > Thoughts ?
> > > > >
> > > >
> > > > Well, in the xml of the error you have quite a lot on info you can
use
> > to decide what to do without changing the sitemap.
> > > > You could use a special selector that selects on the content of an
> > "error namespace" tag to select the appropriate action, or a series of
> > transformers like the log transformer (passthrough) that basically does
the
> > same thing.
> > > > I don't see the need of new semantics.
> > > >
> > > > Nicola Ken Barozzi These are the days of miracle and wonder...
> > > > ...so don't cry baby, don't cry
> > > > <xm...@nicolaken.com> Paul Simon
> > >
> > > I'm afraid this won't work : the XML describing the error is only
> > > available at pipeline processing time, that is _after_ all selectors,
> > > actions and the like have been executed.
> >
> > Before handle-errors the XML describing the error is not there,
> > after you should have another pipeline to spit it out, and if
> > this still doesn't work, a generic html error comes out.
> > In fact in handle-errors, in the current sitemap, you have a
Transformer.
> > If in handle-errors isn't a special pipeline where you can act,
select,etc
> > I think it should become one. This is how it was intended.
>
> You're right : a new pipeline is started in <handle-errors> and you can
> add whatever sitemap construct you want but a generator (the special
> ErrorNotifier generator is set by the engine).
>
> But you can't do anything in this pipeline that depends on the error
> contents : the exception is passed to the ErrorNotifier and isn't
> available in any of the match/act/select that you can put in this
> pipeline.
>
> > > Also, continuing my proposal, it would be good to be able to specify
the
> > > error notifier (the special generator for exceptions). For now it is
> > > hard-coded to use the Notifier which does a nice job for most
> > > exceptions. But we use here some smart exceptions which carry a lot of
> > > useful information and are XMLizable, and I'd like to be able to set
the
> > > generator in handle-errors to process this information.
> >
> > Sorry, I don't get it.
> > The ErrorNotifier checks is an Exception is instanceof Notifiable;
> > if so il spits out all extra descriptions using that interface.
>
> Nope : it builds a Notification with the Exception and uses Notifier to
> produce XML out of it.
I gave a quick look at the source code and I think you are correct.
This is not how I intended it to be... as it is now Notificable is
basically useless...
> > All exceptions in Cocoon should implement that interface, so
> > to be able to provide all the extra stuff you are talking about.
>
> Sorry, but I find Notifiable too constraining in what can be expressed
> using it. While this is good if we can't trigger error-handlers by
> specific exception types, this will be very limiting if we introduce
> this feature.
?
> For a use case, look a my previous post in the thread "[VOTE] directly
> setting variables in sitemap" where I talk about ExplainableException
> to see what I mean.
See that mail...
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<xm...@nicolaken.com> Paul Simon
> Sylvain
>
> > This hasn't been done because when I was starting to ask all to do it
and
> > "enforce" it by adding to the error the phrase "Extra descriptions are
not
> > available because the programmer was too lazy to put them in" ;-)
> > I had to leave the list. So I guess it's my fault not making this clear
> > enough.
> > Implementing this interface you don't need to make a Generator to
> > show the extra descriptions, and your XML is always the same -> you can
> > easily have standard stylesheet for all errors and are guaranteed that
the
> > error notification gets generated.
> >
> > PS. I've just taken a look at the c2 src: Notifiable is called
Notificable,
> > I thought it was changed. I guess it's time I give it another check.
> > Anyway, here is the interface; the extra descritions are the point.
> > Now that I remember I proposed this stuff to the Avalon guys when they
> > were writing the CascadingException stuff and they convinced me that
> > it wasn't general enough for a generic exception (too rich)... but I
forgot
> > to make Notifiable forcibly Cascading...
> > ...don't you think a Notification should be cascading?
> > Anyway, the original-original idea was to use the error namespace xml
> > inline to report xalan warnings and such.
> > Suggestions?
> >
> > public interface Notificable {
> >
> > /**
> > * Gets the Type attribute of the Notificable object
> > */
> > String getType();
> >
> > /**
> > * Gets the Title attribute of the Notificable object
> > */
> > String getTitle();
> >
> > /**
> > * Gets the Source attribute of the Notificable object
> > */
> > String getSource();
> >
> > /**
> > * Gets the Sender attribute of the Notificable object
> > */
> > String getSender();
> >
> > /**
> > * Gets the Message attribute of the Notificable object
> > */
> > String getMessage();
> >
> > /**
> > * Gets the Description attribute of the Notificable object
> > */
> > String getDescription();
> >
> > /**
> > * Gets the ExtraDescriptions attribute of the Notificable object
> > */
> > HashMap getExtraDescriptions();
> > }
> >
> > Nicola Ken Barozzi These are the days of miracle and wonder...
> > ...so don't cry baby, don't cry
> > <xm...@nicolaken.com> Paul Simon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org