Nicola Ken Barozzi wrote: > > Sylvain Wallez wrote: >
<snip/> >> 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 know that (went back to the source), but this property seems to me the most appropriate for this kind of information. > I wrongly assumed that it would be a "level" of error. > We should start giving it a real meaning. Yes, definitely ! >> 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... Not really false ? ;-P >> 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... Cool :-)) > It basically means that you make the mapping of the exception name to > an easy handle... Yep. And the important point is avoiding to writing exception class names in the sitemap. >> 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> Ok. I like this now that we can have a meaningful type on Notifying, and agree to deprecate the "type" attribute on handle-errors. As we say here : "only stupid people don't change their mind" ;) Minor remark : a selector seems more suitable than a matcher as we will most often perform a "switch" on the error type (also shown in your example). We can also have both. > 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"> I don't like this one as it shows explicit class names outside of <map:components> > <map:transform src="SpecificError2html.xsl"/> > <map:serialize status-code="500"/> > <map:match> > > <map:match pattern="*"> This match can even be avoided as we're in the fallback when there is no match above : it's the "otherwise" part of a selector. > <map:serialize status-code="500"/> > <map:match> > > </map:handle-errors> > > > 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. Wouldn't it be better located in <map:components> ? This would allow specific error types to be defined in each sitemap. > Other thoughts? Errmm... I still don't like the implicit generator in <handle-errors>... > 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 Sure we're communicating ! Why does Stefano get nervous ? Because we sometimes communicate loudly ? Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
