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 2003/04/10 17:09:49 UTC
[RT] error-handling for "cocoon:" pipelines
Folks,
Currently <map:handle-errors> in a sitemap is ignored for internal (i.e.
"cocoon:") requests. However, this behaviour is somehow limiting and
Jürgen Seitz and Björn Lütkemeier (guess it's the correct lastname) have
expressed the need to have additional control on this.
They gave only some abstract examples, but a concrete use case for this
is coplets : they are included through a "cocoon:" URI, and, despite of
that, it would be good if a coplet was able to produce a nice error
result instead of just propagating the exception to the upper-level
pipeline (the one that builds the portal page).
There are two ways to consider this problem.
1/ Error handling is controlled by the called pipeline
The contract of a pipeline may include the fact that it produces some
fallback content in case of error. In that case, the current behaviour
that ignores error handlers for internal requests is not good and we
need a way to specify it. This can go through a new "when" attribute on
<map:handle-errors> with the possible values "external", "internal",
"always", the default being "external" since it's the current behaviour.
2/ Error handling is controlled by the caller
We can also consider that the caller knows what to do in case of failure
of the called pipeline, and then want to control this externally. Two
ways are envisioned for this :
2a/ Through the URI, using a new subprotocol :
"cocoon:handle-errors/blah". There's a potential conflict here with the
"cocoon:raw" protocol
2b/ Through a reserved request parameter :
"cocoon:/blah?cocoon-handle-errors=true". Care must be taken to forbid
this parameter for external requests to avoid security holes.
I'm personally in favor of 1/ and do not know about 2/ : is it good for
error handling to be controlled externally ? 1/ and 2/ can also be both
allowed and priority given to the external setting. FS ?
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/10/03 5:09 PM Sylvain Wallez wrote:
> Folks,
>
> Currently <map:handle-errors> in a sitemap is ignored for internal (i.e.
> "cocoon:") requests. However, this behaviour is somehow limiting and
> Jürgen Seitz and Björn Lütkemeier (guess it's the correct lastname) have
> expressed the need to have additional control on this.
>
> They gave only some abstract examples, but a concrete use case for this
> is coplets : they are included through a "cocoon:" URI, and, despite of
> that, it would be good if a coplet was able to produce a nice error
> result instead of just propagating the exception to the upper-level
> pipeline (the one that builds the portal page).
>
> There are two ways to consider this problem.
>
> 1/ Error handling is controlled by the called pipeline
> The contract of a pipeline may include the fact that it produces some
> fallback content in case of error. In that case, the current behaviour
> that ignores error handlers for internal requests is not good and we
> need a way to specify it. This can go through a new "when" attribute on
> <map:handle-errors> with the possible values "external", "internal",
> "always", the default being "external" since it's the current behaviour.
>
> 2/ Error handling is controlled by the caller
> We can also consider that the caller knows what to do in case of failure
> of the called pipeline, and then want to control this externally. Two
> ways are envisioned for this :
> 2a/ Through the URI, using a new subprotocol :
> "cocoon:handle-errors/blah". There's a potential conflict here with the
> "cocoon:raw" protocol
> 2b/ Through a reserved request parameter :
> "cocoon:/blah?cocoon-handle-errors=true". Care must be taken to forbid
> this parameter for external requests to avoid security holes.
>
> I'm personally in favor of 1/ and do not know about 2/ : is it good for
> error handling to be controlled externally ? 1/ and 2/ can also be both
> allowed and priority given to the external setting. FS ?
If I had to choose between 1/ and 2/ I'd choose 1/
I also tend to think that if you need to pass parameters to the cocoon
protocol there is an imbalance somewhere else, but that's only a gut
feeling.
--
Stefano.
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>
>
> <snip/>
>
>>>> 3/ Error handler is called always [1]
>>>
>>>
>>>
>>> Ah, sorry I didn't understood that you were proposing that.
>>
>>
>>
>> It was my way to object to proposed changes :)
>>
>>> But isn't this also too limiting ?
>>
>>
>>
>> First of all, it is straightforward and fare: you have handler - it's
>> always executed. you don't have handler - it's never executed. No
>> automagical stuff you were against recently. And second, it's not
>> limiting: you still can do what these guys were after. Remember the
>> principle:
>>
>> Easy stuff should be easy to do, and complex stuff should be
>> possible to do.
>>
>> (or something like this, don't remember exact wording :)
>
>
>
> "Simple things should be simple, complex things should be possible"
> (Alan Kay)
Thanks!
>>> And writing the same pipeline twice really looks like code
>>> duplication that we all know to be soooo bad ;-)
>>
>>
>>
>> I feel it's not good idea to have pipeline used in both ways -
>> internally via cocoon protocol and externally. I think we have kind
>> of consensus here saying that pipelines accessed by cocoon protocol
>> should be internal-only="true".
>
>
>
> This makes sense. I'm sometimes FS-infected ;-)
Good. I mean good that it makes sense. Not that last part about FS :)
> But this is an incompatible change with what we have today...
And that's why I'm ok with solution 1/ Error handling controlled by the
called pipeline, because it supports both a) current implementation, and
b) solution 3/; even though solution 3/ seems more like clean approach
to me.
Vadim
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
<snip/>
>>> 3/ Error handler is called always [1]
>>
>>
>> Ah, sorry I didn't understood that you were proposing that.
>
>
> It was my way to object to proposed changes :)
>
>> But isn't this also too limiting ?
>
>
> First of all, it is straightforward and fare: you have handler - it's
> always executed. you don't have handler - it's never executed. No
> automagical stuff you were against recently. And second, it's not
> limiting: you still can do what these guys were after. Remember the
> principle:
>
> Easy stuff should be easy to do, and complex stuff should be
> possible to do.
>
> (or something like this, don't remember exact wording :)
"Simple things should be simple, complex things should be possible"
(Alan Kay)
>> And writing the same pipeline twice really looks like code
>> duplication that we all know to be soooo bad ;-)
>
>
> I feel it's not good idea to have pipeline used in both ways -
> internally via cocoon protocol and externally. I think we have kind of
> consensus here saying that pipelines accessed by cocoon protocol
> should be internal-only="true".
This makes sense. I'm sometimes FS-infected ;-)
But this is an incompatible change with what we have today...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/12/03 4:51 PM Jeff Turner wrote:
> On Thu, Apr 10, 2003 at 11:39:55AM -0400, Vadim Gritsenko wrote:
> ....
>
>>I feel it's not good idea to have pipeline used in both ways -
>>internally via cocoon protocol and externally. I think we have kind of
>>consensus here saying that pipelines accessed by cocoon protocol should
>>be internal-only="true".
>
>
> Eek - no!!
>
> A case study: the current Forrest sitemap makes heavy use of cocoon:
> pipelines to define 'source' and 'intermediate' formats:
>
> - Requesting index.xml gives you the doc-v11 format XML
> - Requesting body-index.xml gives you HTML for just the page body
> - Requesting index.html gives you the whole page
>
> These are neatly segregated into separate pipelines. Access to 'source'
> and 'intermediate' pipelines can be disabled easily by switching
> internal-only to "true".
>
> However, when debugging its really useful to have access to
> cocoon:-generated XML, so currently internal-only is switched off.
>
> IMHO, visibility of cocoon: pipelines is something the user should be
> able to decide. There are perfectly good reasons for keeping them
> visible, and its very simple to hide them if necessary.
Good points.
--
Stefano.
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeff Turner wrote:
>On Mon, Apr 14, 2003 at 09:48:46AM -0400, Vadim Gritsenko wrote:
>
>
>>Jeff Turner wrote:
>>
>>
>>
>>>On Thu, Apr 10, 2003 at 11:39:55AM -0400, Vadim Gritsenko wrote:
>>>...
>>>
>>>
>>>
>>>
>>>>I feel it's not good idea to have pipeline used in both ways -
>>>>internally via cocoon protocol and externally. I think we have kind of
>>>>consensus here saying that pipelines accessed by cocoon protocol should
>>>>be internal-only="true".
>>>>
>>>>
>>>Eek - no!!
>>>
>>>
>>>
>...
>
>
>>>IMHO, visibility of cocoon: pipelines is something the user should be
>>>able to decide.
>>>
>>>
>>>
>>Agree.
>>
>>
>>
>>
>>>There are perfectly good reasons for keeping them
>>>visible, and its very simple to hide them if necessary.
>>>
>>>
>>>
>>Ok.
>>
>>Now tell me, why "Eek - no!! "? And no to what?
>>
>>
>
>No to "I think we have kind of consensus here saying that pipelines
>accessed by cocoon protocol should be internal-only="true",
>
You see... All the reasons you gave above about accessing "internal"
pipelines from the outside are mostly about aid in debugging process.
You are not *forced* to expose those pipelines when you go into production.
Thus, what I was trying to say, generally, you do not design your system
to have pipelines working on "both fronts". That's why I said "kind of
consensus".
>from which I (evidently wrongly) read an implication that such pipelines should
>somehow be _forced_ to be internal-only.
>
There were no such implication. Sorry for my unclearness :)
Vadim
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Jeff Turner <je...@apache.org>.
On Mon, Apr 14, 2003 at 09:48:46AM -0400, Vadim Gritsenko wrote:
> Jeff Turner wrote:
>
> >On Thu, Apr 10, 2003 at 11:39:55AM -0400, Vadim Gritsenko wrote:
> >...
> >
> >
> >>I feel it's not good idea to have pipeline used in both ways -
> >>internally via cocoon protocol and externally. I think we have kind of
> >>consensus here saying that pipelines accessed by cocoon protocol should
> >>be internal-only="true".
> >
> >Eek - no!!
> >
...
> >IMHO, visibility of cocoon: pipelines is something the user should be
> >able to decide.
> >
>
> Agree.
>
>
> >There are perfectly good reasons for keeping them
> >visible, and its very simple to hide them if necessary.
> >
>
> Ok.
>
> Now tell me, why "Eek - no!! "? And no to what?
No to "I think we have kind of consensus here saying that pipelines
accessed by cocoon protocol should be internal-only="true", from which I
(evidently wrongly) read an implication that such pipelines should
somehow be _forced_ to be internal-only.
--Jeff
>
> Vadim
>
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeff Turner wrote:
>On Thu, Apr 10, 2003 at 11:39:55AM -0400, Vadim Gritsenko wrote:
>...
>
>
>>I feel it's not good idea to have pipeline used in both ways -
>>internally via cocoon protocol and externally. I think we have kind of
>>consensus here saying that pipelines accessed by cocoon protocol should
>>be internal-only="true".
>>
>>
>
>Eek - no!!
>
>A case study: the current Forrest sitemap makes heavy use of cocoon:
>pipelines to define 'source' and 'intermediate' formats:
>
> - Requesting index.xml gives you the doc-v11 format XML
> - Requesting body-index.xml gives you HTML for just the page body
> - Requesting index.html gives you the whole page
>
Ok (I still remember cocoon-docs webapp).
>These are neatly segregated into separate pipelines. Access to 'source'
>and 'intermediate' pipelines can be disabled easily by switching
>internal-only to "true".
>
Ok.
>However, when debugging its really useful to have access to
>cocoon:-generated XML,
>
Agree.
> so currently internal-only is switched off.
>
Ok.
>IMHO, visibility of cocoon: pipelines is something the user should be
>able to decide.
>
Agree.
>There are perfectly good reasons for keeping them
>visible, and its very simple to hide them if necessary.
>
Ok.
Now tell me, why "Eek - no!! "? And no to what?
Vadim
RE: [RT] error-handling for "cocoon:" pipelines
Posted by Geoff Howard <co...@leverageweb.com>.
> -----Original Message-----
> From: Jeff Turner [mailto:jefft@apache.org]
> On Thu, Apr 10, 2003 at 11:39:55AM -0400, Vadim Gritsenko wrote:
> ...
> > I feel it's not good idea to have pipeline used in both ways -
> > internally via cocoon protocol and externally. I think we have kind of
> > consensus here saying that pipelines accessed by cocoon protocol should
> > be internal-only="true".
>
> Eek - no!!
<snip/>
>
> IMHO, visibility of cocoon: pipelines is something the user should be
> able to decide. There are perfectly good reasons for keeping them
> visible, and its very simple to hide them if necessary.
>
I absolutely agree with this. What would the reason be to restrict them?
Geoff
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Jeff Turner <je...@apache.org>.
On Thu, Apr 10, 2003 at 11:39:55AM -0400, Vadim Gritsenko wrote:
...
> I feel it's not good idea to have pipeline used in both ways -
> internally via cocoon protocol and externally. I think we have kind of
> consensus here saying that pipelines accessed by cocoon protocol should
> be internal-only="true".
Eek - no!!
A case study: the current Forrest sitemap makes heavy use of cocoon:
pipelines to define 'source' and 'intermediate' formats:
- Requesting index.xml gives you the doc-v11 format XML
- Requesting body-index.xml gives you HTML for just the page body
- Requesting index.html gives you the whole page
These are neatly segregated into separate pipelines. Access to 'source'
and 'intermediate' pipelines can be disabled easily by switching
internal-only to "true".
However, when debugging its really useful to have access to
cocoon:-generated XML, so currently internal-only is switched off.
IMHO, visibility of cocoon: pipelines is something the user should be
able to decide. There are perfectly good reasons for keeping them
visible, and its very simple to hide them if necessary.
--Jeff
> Vadim
>
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>> <snip/>
>>
>>> There are two ways to consider this problem.
>>>
>>> 1/ Error handling is controlled by the called pipeline
>>
>>
>>
>> <snip/>
>>
>>> 2/ Error handling is controlled by the caller
>>
>>
>>
>>
>> <snip/>
>> Ahem... Let me repeat myself as I've got no feedback:
>>
>> 3/ Error handler is called always [1]
>
>
>
> Ah, sorry I didn't understood that you were proposing that.
It was my way to object to proposed changes :)
> But isn't this also too limiting ?
First of all, it is straightforward and fare: you have handler - it's
always executed. you don't have handler - it's never executed. No
automagical stuff you were against recently. And second, it's not
limiting: you still can do what these guys were after. Remember the
principle:
Easy stuff should be easy to do, and complex stuff should be
possible to do.
(or something like this, don't remember exact wording :)
> And writing the same pipeline twice really looks like code duplication
> that we all know to be soooo bad ;-)
I feel it's not good idea to have pipeline used in both ways -
internally via cocoon protocol and externally. I think we have kind of
consensus here saying that pipelines accessed by cocoon protocol should
be internal-only="true".
Vadim
> Sylvain
>
>> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998037007592&w=2
>
>
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
> <snip/>
>
>> There are two ways to consider this problem.
>>
>> 1/ Error handling is controlled by the called pipeline
>
>
> <snip/>
>
>> 2/ Error handling is controlled by the caller
>
>
>
> <snip/>
> Ahem... Let me repeat myself as I've got no feedback:
>
> 3/ Error handler is called always [1]
Ah, sorry I didn't understood that you were proposing that. But isn't
this also too limiting ? And writing the same pipeline twice really
looks like code duplication that we all know to be soooo bad ;-)
Sylvain
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998037007592&w=2
>
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] error-handling for "cocoon:" pipelines
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
<snip/>
> There are two ways to consider this problem.
>
> 1/ Error handling is controlled by the called pipeline
<snip/>
> 2/ Error handling is controlled by the caller
<snip/>
Ahem... Let me repeat myself as I've got no feedback:
3/ Error handler is called always [1]
Vadim
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998037007592&w=2