From cocoon-dev-return-19493-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Tue Dec 04 17:35:39 2001 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 28524 invoked by uid 500); 4 Dec 2001 17:35:39 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 28497 invoked from network); 4 Dec 2001 17:35:36 -0000 Message-ID: <011901c17ce9$d6c69fd0$670004c0@PC103> From: "Nicola Ken Barozzi" To: References: <00be01c17cd5$2a642910$670004c0@PC103> <3C0D0349.ABA2667B@anyware-tech.com> Subject: Re: Sitemap error-handling [was : [VOTE] directly setting variables in sitemap] Date: Tue, 4 Dec 2001 18:33:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Sylvain Wallez" To: 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" > > To: > > 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" > > To: "cocoon-dev" > > Sent: Tuesday, December 04, 2001 10:13 AM > > Subject: Sitemap error-handling [was : [VOTE] directly setting variables in > > sitemap] > > > > > > > > nicolaken@supereva.it a écrit : > > > > > > > > > > > > > > > > > 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 : > > > > > > > > > > > > > > > > exception="org.apache.avalon.framework.configuration.ConfigurationError"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > exception="java.lang.security.AccessControlException"> > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > 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 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 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 > > 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