To add my 2 cents from user perpective (without knowing anything about sitemap error hadling)
1. Having mapping to exception name might not me enough. Exceptions thrown in EJBs are often wrapped in RemoteException, also custom Exceptions might be of the same type but have different id. I guess I would need a custom error matcher/selector ? 2. Going to different url (pipe) on given error should be possible. I guess this will only work for actions and generators (before any data is sent back) 3. All original request/session/sitemap params should be avaiable to the error pipe so I can do both PageA --> PageA (with errors/original data), PageA --> error page (with errors) --> PageA (with original data) 4. One should be able set new params. 5. Exception type and message should be available as parameters. I'm sorry if some of these are already implemented, impossible, or obvious. Thanks, Artur... > -----Original Message----- > From: Michael Melhem [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 10, 2002 10:46 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Extending Sitemap Error Handling > > > On Wed, Jul 10, 2002 at 03:32:42PM +0200, Nicola Ken Barozzi wrote: > > > > Sylvain Wallez wrote: > > >Michael Melhem wrote: > > > > > >>Dear Cocoon community, > > >> > > >>It seems to me that pipelines can only handle two error cases: Namely > > >>error 500 (General Exception) and error 404 (ResourceNotFoundException). > > >> > > >>There appears to be no way currently to handle specific errors that > > >>might be thrown by pipeline components other than to render a general > > >>Error 500 page. Am I mistaken? > > >> > > >>For example, it may be the case that a custom built generator could > > >>throw custom Exceptions that a developer would like to handle in a > > >>specific fashion. > > >> > > >>To that end, I propose that pipeline be extendend so that it they can > > >>handle X number of errors depending on the amount of > > >><map:handle-errors> defined in the sitemap for that pipeline. > > >> > > >><sitemap> > > >> ... > > >> > > >> <map:handle-errors type="500"> > > >> <map:transform src="stylesheets/error2html.xsl"/> > > >> <map:serialize/> > > >> </map:handle-errors> > > >> > > >> <map:handle-errors type="404"> > > >> <map:transform src="stylesheets/error2html.xsl"/> > > >> <map:serialize /> > > >> </map:handle-errors> > > >> > > >> <!-- one more or extra error-handles --> > > >> <map:handle-errors type="someSpecificException"> > > >> <-- "type" here could me some sort of short code or the actual > > >> full name of the Exception class? --> > > >> <map:transform src="stylesheets/SpecificError2html.xsl"/> > > >> <map:serialize status-code="500"/> > > >> </map:handle-errors> > > >> > > >> etc.. > > >></sitemap> > > >> > > >>Does anyone see any problems with this approach? Comments? > > >> > > >> > > > > > >I like this, and proposed something similar back in december (see > > >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100739814405987&w=2) > > > > > >It didn't had much acceptance at that time both because it involved > > >class names in the pipelines and because Nicola Ken was refactoring > > >error notification ;) > > > > And because it isn't strictly needed ;-) > > > > >But I still would like to have something like this, as I think having to > > >write a <handle-errors type="500"> and then using a <map:select> to > > >select depending on the error type is counter-intuitive. > > > > no, you would have a <handle-errors>, we decided that type="" would be > > deprecated, since it's redundant. > > > > >When an exception occurs, the sitemap engine builds a Notifying object > > >that is available within the <handle-errors>. This Notifying has a > > >getType() method which is exactly what we need for this "type" attribute. > > > > There are many other attributes, not only getType. > > I wrongly assumed that it would be a "level" of error. > > We should start giving it a real meaning. > > > > >But getType() always returns "error" unless your exception implements > > >Notifying (which none does, and IMO having an exception implement > > >Notifying to drive sitemap error-handling is mixing concerns). > > > > Not really true... > > > > > So we > > >could configure the NotifyingBuilder so that it can associate exception > > >classes to notifying types. > > > > > ><notifying-builder> > > > <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/> > > > <type name="500" src="org.apache.cocoon.ProcessingException"/> > > > <type name="access-denied" src="java.lang.SecurityException"/> > > > <type name="my-error-case" src="my.app.someSpecificException"/> > > ></notifying-builder> > > > > This I like better... > > It basically means that you make the mapping of the exception name to an > > easy handle... > > > > >Notice the two first lines that ensure compatibility with what we have > > >today. > > > > > >And then in the pipelines : > > ><map:handle-errors type="access-denied"> > > > <map:transform src="accessDenied.xsl"/> > > > <map:serialize/> > > ></map:handle-errors> > > > > > ><map:handle-errors type="my-error-case"> > > > <map:transform src="SpecificError2html.xsl"/> > > > <map:serialize status-code="500"/> > > ></map:handle-errors> > > > > > >Thoughts ? > > > > I would rewrite your case like this: > > > > <notifying-builder> > > <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/> > > <type name="500" src="org.apache.cocoon.ProcessingException"/> > > <type name="access-denied" src="java.lang.SecurityException"/> > > <type name="my-error-case" src="my.app.someSpecificException"/> > > </notifying-builder> > > > > <map:handle-errors> > > > > <map:match type="error" pattern="access-denied"> > > <map:transform src="accessDenied.xsl"/> > > <map:serialize/> > > <map:match> > > > > <map:match type="error" pattern="my-error-case"> > > <map:transform src="SpecificError2html.xsl"/> > > <map:serialize status-code="500"/> > > <map:match> > > > > <map:match pattern="*"> > > <map:serialize status-code="500"/> > > <map:match> > > > > </map:handle-errors> > > > > But we could simply do: > > > > <map:handle-errors> > > > > <map:match type="error" pattern="access-denied"> > > <map:transform src="accessDenied.xsl"/> > > <map:serialize/> > > <map:match> > > > > <map:match type="exception" pattern="my.app.someSpecificException"> > > <map:transform src="SpecificError2html.xsl"/> > > <map:serialize status-code="500"/> > > <map:match> > > > > <map:match pattern="*"> > > <map:serialize status-code="500"/> > > <map:match> > > > > </map:handle-errors> > > Matching for exception types within the handle-errors block - This I > like! Because (can I start a sentence with "beacuse"?..hmm) the whole point is to >make sure that exceptions can be easly > and intuitively handled depending on error type. > > Regards > Michael Melhem > > > > > > Of course, we will need to put a > > > > <notifying-builder> > > <type name="404" src="org.apache.cocoon.ResourceNotFoundException"/> > > <type name="500" src="org.apache.cocoon.ProcessingException"/> > > <type name="access-denied" src="java.lang.SecurityException"/> > > <type name="my-error-case" src="my.app.someSpecificException"/> > > </notifying-builder> > > > > thing in cocoon.xconf to handle the major types of errors, so that the > > match type="exception" is not used a lot, or even at all. > > > > Other thoughts? > > > > Keep calm Stefano, I know you get nervous when Sylvain and I discuss at > > this speed, but believe me, we are communicating, it's not noise ;-P > > > > -- > > Nicola Ken Barozzi [EMAIL PROTECTED] > > - verba volant, scripta manent - > > (discussions get forgotten, just code remains) > > --------------------------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
