You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/03/08 12:11:29 UTC
[RT] Forwarding of internal pipeline calls
While using internal cocoon redirects, I found out that there are
potential problems with error handling (it might be that we have
discusses this already...).
Now, if you do a:
<map:redirect-to uri="cocoon://something"/>
than this is an internal pipeline call (and not a new http request).
This has of course some advantages (e.g. performance etc), but
has imho the drawback that in this case, the error handling
of the calling pipeline is *always* used. This means if an error
occurs while processing the "something" pipeline, the error
handler of the pipeline containing the redirect-to is invoked.
Now, in general this might be a good solution for internal pipeline
calls when they are used in a map:generate etc., but it's imho
a little unusal for a redirect.
We had recently the discussion on this list, if we need a general
solution to specify which error handler is used for internal pipeline
calls. I discussed this a little bit with Vadim on IRC during our
first friday and he suggest to specify this not on the caller but
on the called pipeline. So the map:pipeline containing the
"something" pipeline specifies what to do. Regardless if this is
the better choice than specifying it in the uri ("cocoon:...."),
it's technically nearly impossible. When the internal pipeline
is called, everything happens outside the treehandler and there is
no real chance to get the error handler etc. (Of course we could
change something here and there and then it will work.)
So, I just tried the other way:
<map:redirect-to uri="cocoon://something?cocoon:forward=true"/>
The current implementation I have can only be used for redirects,
although it's fairly simple to extend it to be used in
map:generate etc. as well.
WDYT? Is this of general interest?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
Re: [RT] Forwarding of internal pipeline calls
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
...
>>I'd prefer not to pollute
>>request parameters with internal cocoon stuff. This reminds
>>me of recently fixed header action which was iterating over
>>sitemap parameters. Similarly, users may rely in theirs code
>>on request parameters and iterate over them. Adding cocoon's
>>internal stuff as request parameters will break this. And
>>same may happen with source cache URIs discussed recently...
>>
>>
>No, not really. The clever trick is to use invalid request parameter
>names that have a kind of namespace prefix, like cocoon:forward.
>All parameters with this namespace are filtered out by the core
>and not visible for the internal pipeline.
>
>
But then, if those parameters are filtered out, in case of cache URIs,
it makes more sense to have
cache:main@60:http://www.apache.org
as you don't have to do any filtering at all, because you are not
polluting URI with invalid parameters in the first place! And it seems
that request parameter cocoon:forward got -1's already...
Vadim
RE: [RT] Forwarding of internal pipeline calls
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
> > Secondly, we have to define means for handle-errors to be used on
> > internal requests (i.e. SitemapSource). And in that case, as you
> > outlined, this can be determined by the caller (the place where the
> > "cocoon:" occurs) or in the callee (the called pipeline).
> >
> > - by the caller, I don't see any other way than using an additional
> > parameter as you proposed above. But instead of "cocoon:forward",
> > naming it "cocoon:handle-errors" seems more adequate.
>
>
> Do you mean request parameter here?
Yes.
> I'd prefer not to pollute
> request parameters with internal cocoon stuff. This reminds
> me of recently fixed header action which was iterating over
> sitemap parameters. Similarly, users may rely in theirs code
> on request parameters and iterate over them. Adding cocoon's
> internal stuff as request parameters will break this. And
> same may happen with source cache URIs discussed recently...
>
No, not really. The clever trick is to use invalid request parameter
names that have a kind of namespace prefix, like cocoon:forward.
All parameters with this namespace are filtered out by the core
and not visible for the internal pipeline.
The question is, what is better, placing it on the caller or on
the called pipeline (doing both seems a little bit like FS). I
don't know.
Carsten
Re: [RT] Forwarding of internal pipeline calls
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
...
> Secondly, we have to define means for handle-errors to be used on
> internal requests (i.e. SitemapSource). And in that case, as you
> outlined, this can be determined by the caller (the place where the
> "cocoon:" occurs) or in the callee (the called pipeline).
>
> - by the caller, I don't see any other way than using an additional
> parameter as you proposed above. But instead of "cocoon:forward",
> naming it "cocoon:handle-errors" seems more adequate.
Do you mean request parameter here? I'd prefer not to pollute request
parameters with internal cocoon stuff. This reminds me of recently fixed
header action which was iterating over sitemap parameters. Similarly,
users may rely in theirs code on request parameters and iterate over
them. Adding cocoon's internal stuff as request parameters will break
this. And same may happen with source cache URIs discussed recently...
> - by the callee, this can be done using an additional attribute on the
> error-handler. What comes to mind is <map:handle-errors
> requests="external|internal|all">
+1. This one is nice idea. When we discussed this with Carsten last
time, I came up only with pipeline parameter. Adding this parameter on
handle-errors element makes more sense.
As an alternative to "requests" attribute, I can suggest "process".
Vadim
RE: [RT] Forwarding of internal pipeline calls
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
>
> Ah yes, I understand the "technically nearly impossible" now:
> - pipeline building is always under control of the
> treeprocessor. So in that phase, this is possible.
Yes.
> - for external requests, pipeling processing occurs within
> the treeprocessor (in the node that closes the pipeline), so
> it's possible here also
Yes.
> - for internal requests, pipeline processing occurs outside
> of the treeprocessor, when the caller uses
> SitemapSource.getInputStream(). This is where the difficult
> point is...
Yupp.
>
> Mmmh... what we can do is give the SitemapSource an
> error-handling processor which would just wrap the
> error-handler (if any) in the <map:pipeline> where the
> pipeline was built. The SitemapSource can then call that
> special processor if a problem arises during pipeline execution.
>
> The means for the TreeProcessor to pass this special
> error-handling processor to the SitemapSource can be the
> MutableEnvironmentFacade that's already considered as a
> special case by the TreeProcessor. This class is a kind of
> "backwards communication channel" from the Processor to the
> SitemapSource.
>
> I think this should work, and this solution has no impact on
> the existing interfaces.
>
Sounds good (and more important it sounds possible :) ). So, we just
have to do some votes (about the redirect=forwarding) and the
correct notion of this one, implement it and voila have this
nice little feature many users ask for.
Great!
Carsten
Re: [RT] Forwarding of internal pipeline calls
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Sorry, what is "technically nearly impossible"??
>>
>>
>Without changing the interfaces and without having a clean separation of concerns, it's not possible. Of course if we change some core interfaces, the treeprocessor and the pipeline implementation, this is possible. Something along these lines.
>
>
>>>So, I just tried the other way:
>>><map:redirect-to uri="cocoon://something?cocoon:forward=true"/>
>>>
>>>The current implementation I have can only be used for redirects, although it's fairly simple to extend it to be used in map:generate etc. as well.
>>>
>>>WDYT? Is this of general interest?
>>>
>>This question comes regularly on the table. Maybe it's time to give it an answer now :-)
>>
>
>YES :)
>
>
>>The current state is that <map:handle-errors> is considered only for requests coming directly from the outside world, and not for internal requests (i.e. "cocoon:").
>>
>>Firstly, this behaviour is IMO bad for forwards (redirects to "cocoon:"): forwarding should fully delegate the request, including error handling. Fixing this can be accomplished easily by overriding isInternal() in TreeProcessor.ForwardEnvironmentWrapper: instead of always returning false, we can delegate the call to the wrapped environment (will return true on http and cli environments).
>>
>>
>
>Yes, that's what I did - and it seems to work. Now, the question is if we can simply change this for redirect's?
>
>
Well, that's a first step that will give consistency to the error
handling for external requests ;-)
>>Secondly, we have to define means for handle-errors to be used on internal requests (i.e. SitemapSource). And in that case, as you outlined, this can be determined by the caller (the place where the "cocoon:" occurs) or in the callee (the called pipeline).
>>
>>- by the caller, I don't see any other way than using an additional parameter as you proposed above. But instead of "cocoon:forward", naming it "cocoon:handle-errors" seems more adequate.
>>
>>
>Ok.
>
>
>>- by the callee, this can be done using an additional attribute on the error-handler. What comes to mind is <map:handle-errors requests="external|internal|all">
>>
>>Policy defined by the caller should have precedence over the one defined in the pipeline.
>>
>>How does it sound?
>>
>>
>Good, but as I tried to state, it's not that easy to get the second implemented. The pipeline is currently executed in the ProcessingPipeline object, so that's were the generator is started etc. When an exception occurs during pipeline processing it happens there. And the pipeline doesn't have any connection to the tree processor or to the handle errors part etc. So that would be the challenge.
>
>
Ah yes, I understand the "technically nearly impossible" now:
- pipeline building is always under control of the treeprocessor. So in
that phase, this is possible.
- for external requests, pipeling processing occurs within the
treeprocessor (in the node that closes the pipeline), so it's possible
here also
- for internal requests, pipeline processing occurs outside of the
treeprocessor, when the caller uses SitemapSource.getInputStream(). This
is where the difficult point is...
Mmmh... what we can do is give the SitemapSource an error-handling
processor which would just wrap the error-handler (if any) in the
<map:pipeline> where the pipeline was built. The SitemapSource can then
call that special processor if a problem arises during pipeline execution.
The means for the TreeProcessor to pass this special error-handling
processor to the SitemapSource can be the MutableEnvironmentFacade
that's already considered as a special case by the TreeProcessor. This
class is a kind of "backwards communication channel" from the Processor
to the SitemapSource.
I think this should work, and this solution has no impact on the
existing interfaces.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Forwarding of internal pipeline calls
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Sorry, what is "technically nearly impossible"??
>
Without changing the interfaces and without having a clean separation
of concerns, it's not possible. Of course if we change some core
interfaces, the treeprocessor and the pipeline implementation,
this is possible. Something along these lines.
> >So, I just tried the other way:
> ><map:redirect-to uri="cocoon://something?cocoon:forward=true"/>
> >
> >The current implementation I have can only be used for redirects,
> >although it's fairly simple to extend it to be used in map:generate
> >etc. as well.
> >
> >WDYT? Is this of general interest?
> >
> >
>
> This question comes regularly on the table. Maybe it's time
> to give it an answer now :-)
>
YES :)
> The current state is that <map:handle-errors> is considered
> only for requests coming directly from the outside world, and
> not for internal requests (i.e. "cocoon:").
>
> Firstly, this behaviour is IMO bad for forwards (redirects to
> "cocoon:"): forwarding should fully delegate the request,
> including error handling. Fixing this can be accomplished
> easily by overriding
> isInternal() in TreeProcessor.ForwardEnvironmentWrapper:
> instead of always returning false, we can delegate the call
> to the wrapped environment (will return true on http and cli
> environments).
Yes, that's what I did - and it seems to work. Now, the question
is if we can simply change this for redirect's?
>
> Secondly, we have to define means for handle-errors to be
> used on internal requests (i.e. SitemapSource). And in that
> case, as you outlined, this can be determined by the caller
> (the place where the "cocoon:" occurs) or in the callee (the
> called pipeline).
>
> - by the caller, I don't see any other way than using an
> additional parameter as you proposed above. But instead of
> "cocoon:forward", naming it "cocoon:handle-errors" seems more
> adequate.
>
Ok.
> - by the callee, this can be done using an additional
> attribute on the error-handler. What comes to mind is
> <map:handle-errors requests="external|internal|all">
>
> Policy defined by the caller should have precedence over the
> one defined in the pipeline.
>
> How does it sound?
>
Good, but as I tried to state, it's not that easy to get the second
implemented. The pipeline is currently executed in the ProcessingPipeline
object, so that's were the generator is started etc. When an
exception occurs during pipeline processing it happens there. And
the pipeline doesn't have any connection to the tree processor or
to the handle errors part etc. So that would be the challenge.
Carsten
Re: [RT] Forwarding of internal pipeline calls
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>While using internal cocoon redirects, I found out that there are
>potential problems with error handling (it might be that we have
>discusses this already...).
>
>Now, if you do a:
><map:redirect-to uri="cocoon://something"/>
>
>than this is an internal pipeline call (and not a new http request).
>This has of course some advantages (e.g. performance etc), but
>has imho the drawback that in this case, the error handling
>of the calling pipeline is *always* used. This means if an error
>occurs while processing the "something" pipeline, the error
>handler of the pipeline containing the redirect-to is invoked.
>
>Now, in general this might be a good solution for internal pipeline
>calls when they are used in a map:generate etc., but it's imho
>a little unusal for a redirect.
>
>We had recently the discussion on this list, if we need a general
>solution to specify which error handler is used for internal pipeline
>calls. I discussed this a little bit with Vadim on IRC during our
>first friday and he suggest to specify this not on the caller but
>on the called pipeline. So the map:pipeline containing the
>"something" pipeline specifies what to do. Regardless if this is
>the better choice than specifying it in the uri ("cocoon:...."),
>it's technically nearly impossible. When the internal pipeline
>is called, everything happens outside the treehandler and there is
>no real chance to get the error handler etc. (Of course we could
>change something here and there and then it will work.)
>
>
Sorry, what is "technically nearly impossible"??
>So, I just tried the other way:
><map:redirect-to uri="cocoon://something?cocoon:forward=true"/>
>
>The current implementation I have can only be used for redirects,
>although it's fairly simple to extend it to be used in
>map:generate etc. as well.
>
>WDYT? Is this of general interest?
>
>
This question comes regularly on the table. Maybe it's time to give it
an answer now :-)
The current state is that <map:handle-errors> is considered only for
requests coming directly from the outside world, and not for internal
requests (i.e. "cocoon:").
Firstly, this behaviour is IMO bad for forwards (redirects to
"cocoon:"): forwarding should fully delegate the request, including
error handling. Fixing this can be accomplished easily by overriding
isInternal() in TreeProcessor.ForwardEnvironmentWrapper: instead of
always returning false, we can delegate the call to the wrapped
environment (will return true on http and cli environments).
Secondly, we have to define means for handle-errors to be used on
internal requests (i.e. SitemapSource). And in that case, as you
outlined, this can be determined by the caller (the place where the
"cocoon:" occurs) or in the callee (the called pipeline).
- by the caller, I don't see any other way than using an additional
parameter as you proposed above. But instead of "cocoon:forward", naming
it "cocoon:handle-errors" seems more adequate.
- by the callee, this can be done using an additional attribute on the
error-handler. What comes to mind is <map:handle-errors
requests="external|internal|all">
Policy defined by the caller should have precedence over the one defined
in the pipeline.
How does it sound?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Forwarding of internal pipeline calls
Posted by Unico Hommes <un...@hippo.nl>.
Carsten Ziegeler wrote:
>Unico Hommes wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>
>>>Unico Hommes wrote:
>>>
>>>
>>>
>>>
>>>
>>>>I am just thinking whether it'd be worth a separate
>>>>
>>>>
>>protocol something
>>
>>
>>>>like forward://something ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Yes, I thought of this as well. Unfortunately we have to
>>>
>>>
>>many hardcoded
>>
>>
>>>places, where against the protocol name "cocoon:" is tested.
>>>
>>>
>>So if we
>>
>>
>>>provide a new protocol we have to change all those places as well.
>>>
>>>And we have to come up with a good name, as <map:generate
>>>src="forward://something"/> might look at little bit strange :)
>>>
>>>
>>>
>>>
>>O I thought you meant by forward the behavior that error
>>handling would
>>be forwarded to the called pipeline and that the default
>>behavior should
>>be that errors are handled by the calling pipeline.
>>
>>
>Yes, I meant that :) I think the word "forward" is good for a
>redirect (map:redirect-to uri="forward://sggd" but not
>for a general source definition (map:generate src="forward://")
>
>
>
>
Hmm I see. It would be more clear if the opposite of forward:// would be
include:// (also the servlet api terminology) but we already have
cocoon:// . I guess it's not worth deprecating cocoon:// in favor of
forward:// and include:// would it?
>>In that
>>case it may
>>be a lot less places where it had to change?
>>
>>
>Why? Perhaps we meant the same?
>
>
>
>>What should be the default behavior?
>>
>>
>>
>The default should be as it is now.
>
>
>
Confusion abound :-) I see I was mixing things up. Sorry for that. I get
it now.
Unico
RE: [RT] Forwarding of internal pipeline calls
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Unico Hommes wrote:
>
> Carsten Ziegeler wrote:
>
> >Unico Hommes wrote:
> >
> >
> >
> >>I am just thinking whether it'd be worth a separate
> protocol something
> >>like forward://something ?
> >>
> >>
> >>
> >Yes, I thought of this as well. Unfortunately we have to
> many hardcoded
> >places, where against the protocol name "cocoon:" is tested.
> So if we
> >provide a new protocol we have to change all those places as well.
> >
> >And we have to come up with a good name, as <map:generate
> >src="forward://something"/> might look at little bit strange :)
> >
> >
>
> O I thought you meant by forward the behavior that error
> handling would
> be forwarded to the called pipeline and that the default
> behavior should
> be that errors are handled by the calling pipeline.
Yes, I meant that :) I think the word "forward" is good for a
redirect (map:redirect-to uri="forward://sggd" but not
for a general source definition (map:generate src="forward://")
> In that
> case it may
> be a lot less places where it had to change?
Why? Perhaps we meant the same?
> What should be the default behavior?
>
The default should be as it is now.
Carsten
Re: [RT] Forwarding of internal pipeline calls
Posted by Unico Hommes <un...@hippo.nl>.
Carsten Ziegeler wrote:
>Unico Hommes wrote:
>
>
>
>>I am just thinking whether it'd be worth a separate protocol
>>something like forward://something ?
>>
>>
>>
>Yes, I thought of this as well. Unfortunately we have to many hardcoded
>places, where against the protocol name "cocoon:" is tested. So if
>we provide a new protocol we have to change all those places as well.
>
>And we have to come up with a good name, as
><map:generate src="forward://something"/>
>might look at little bit strange :)
>
>
O I thought you meant by forward the behavior that error handling would
be forwarded to the called pipeline and that the default behavior should
be that errors are handled by the calling pipeline. In that case it may
be a lot less places where it had to change?
What should be the default behavior?
--
Unico
AW: [RT] Forwarding of internal pipeline calls
Posted by Marco Rolappe <m_...@web.de>.
> -----Ursprungliche Nachricht-----
> Von: dev-return-57149-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-57149-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Stefano Mazzocchi
> Gesendet: Dienstag, 9. Marz 2004 06:13
> An: dev@cocoon.apache.org
> Betreff: Re: AW: [RT] Forwarding of internal pipeline calls
>
>
> Marco Rolappe wrote:
>
> > well, I'll stop now...
>
> noooooooooooooo, don't :-)
:-) I'll give the stuff a bit more time to breed and a bit more 'food' to
swallow and then see what comes out.
I see the basic shape of the picture but it's only a sketch of MTRT (more
than random thoughts ;-).
> as sinful as it might seem around here, I have been thinking about a
> non-XML version of a sitemap syntax and it is surprisingly similar to
> what you described.
I think apart from being easily digested via Configuration's et al. there's
no strong reason to being forced to that 'syntax' and I surely don't think
of it as a sin (what's that? ;-). and the simple and powerful structure of
the pipelines makes a minimal syntax possible;
when you declare a generator pipeline, the first component has to be a
generator and the remaining (if any) have to be transformers. the same
principle also for the other pipeline types. so you end up with simple
names, as in the example I gave.
>
> DISCLAIMER: before people run off to their bosses and pull the emergency
> break, remember: this is an RT, this is the place where crazy new ideas
> are discussed and distroyed... what remains standing might be the next
> big innovation in the field ;-)
yeah, we'll see what comes out. but since 'ein bild sagt mehr als tausend
worte' I'll try to come back showing a picture instead of letting floods of
words break open.
Re: AW: [RT] Forwarding of internal pipeline calls
Posted by Stefano Mazzocchi <st...@apache.org>.
Marco Rolappe wrote:
> well, I'll stop now...
noooooooooooooo, don't :-)
as sinful as it might seem around here, I have been thinking about a
non-XML version of a sitemap syntax and it is surprisingly similar to
what you described.
DISCLAIMER: before people run off to their bosses and pull the emergency
break, remember: this is an RT, this is the place where crazy new ideas
are discussed and distroyed... what remains standing might be the next
big innovation in the field ;-)
--
Stefano.
AW: [RT] Forwarding of internal pipeline calls
Posted by Marco Rolappe <m_...@web.de>.
I don't really want to delve too deeply into this (the mail would become
very long ;-) but...
the core problem IMO is the current concept(s) of the sitemap; I had that
feeling already when starting with Cocoon, hearing about the 'sitemap' and
then looking at it and being confused.
and when seeing a proposal like a separate protocol for forwarding I find it
fairly obvious that there's something wrong.
one of the core problems I see is missing SoC. the most powerful thing and
the core concept (for me) are the processing pipelines; they are supposed to
produce a deliverable response by using a generator, transformers and a
serializer. the missing/weak SoC IMO already starts with Reader's; these
haven't really anything to do with (XML/SAX) processing pipelines.
I think the reason(ing) for forcing Reader's into the pipeline concept
already leads to the core problem; requests are always mapped to pipelines.
I don't know what you people use internal 'redirects' for, but I mainly use
it for delegation or aliasing respectively. the reasoning for internal
'redirects' I assume are the same as for Reader's. force everything into a
pipeline (which still is an XML processing pipeline).
all of it would be so much cleaner, more elegant, more
maintainable/resuable... if concerns were better separated; declaration of
URI space handled by sitemap (think contract/interface), definition of URI
space (think implementation, including useful concepts like inheritance),
definition of processing pipelines and respective pipeline components.
you would map URIs/requests, e.g. to 'request processors', not directly to
pipelines (which are still XML processing pipelines ;-) here you could
eliminate the aliasing internal 'redirect'; you just map a set of requests
to the same processing:
"foo(*)", "bar(*)" -> pipeline baz(param: {1})
the delegating internal 'redirect' wouldn't be needed anymore since you
could directly call pipelines by name (which is also more maintainable than
making it part of the URI space). think of <map:pipeline
internal-only="true">...
or you map to a flow controller, or to a reader, ...
there's so many problems such a cleanup would solve...
I've been thinking about it for a while and I'm considering starting an
alternative Processor implementation.
example snippet (<map:resource> converted to a serializer):
...
// serializer contract: SAX input, no SAX output
serializer amore2pml
{
xsltc src: cocoon://emotion/core/stylesheets/layout.xsl
cinclude support-caching: true, expires: 86400
xsltc src: stylesheets/vodafone-de.xsl, contextpath:
{sitemap-context:context-path}
xsltc src: stylesheets/adapt.xsl
i18n locale: de
xsltc src: cocoon://emotion/core/stylesheets/amore2pml.xsl,
service-name: eMotion
vizzavi-image
partner-ml
}
...
generators:
// generator contract: no SAX input, SAX output
generator header(which)
{
file src: headers/{which}.xml // use file generator
}
generator footer(which)
{
file src: footers/{which}.xml
}
well, I'll stop now...
> -----Ursprungliche Nachricht-----
> Von: dev-return-57060-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-57060-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Carsten Ziegeler
> Gesendet: Montag, 8. Marz 2004 12:31
> An: dev@cocoon.apache.org
> Betreff: RE: [RT] Forwarding of internal pipeline calls
>
>
> Unico Hommes wrote:
>
> > I am just thinking whether it'd be worth a separate protocol
> > something like forward://something ?
> >
> Yes, I thought of this as well. Unfortunately we have to many hardcoded
> places, where against the protocol name "cocoon:" is tested. So if
> we provide a new protocol we have to change all those places as well.
>
> And we have to come up with a good name, as
> <map:generate src="forward://something"/>
> might look at little bit strange :)
>
> Carsten
>
RE: [RT] Forwarding of internal pipeline calls
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Unico Hommes wrote:
> I am just thinking whether it'd be worth a separate protocol
> something like forward://something ?
>
Yes, I thought of this as well. Unfortunately we have to many hardcoded
places, where against the protocol name "cocoon:" is tested. So if
we provide a new protocol we have to change all those places as well.
And we have to come up with a good name, as
<map:generate src="forward://something"/>
might look at little bit strange :)
Carsten
Re: [RT] Forwarding of internal pipeline calls
Posted by Unico Hommes <un...@hippo.nl>.
Carsten Ziegeler wrote:
>While using internal cocoon redirects, I found out that there are
>potential problems with error handling (it might be that we have
>discusses this already...).
>
>Now, if you do a:
><map:redirect-to uri="cocoon://something"/>
>
>than this is an internal pipeline call (and not a new http request).
>This has of course some advantages (e.g. performance etc), but
>has imho the drawback that in this case, the error handling
>of the calling pipeline is *always* used. This means if an error
>occurs while processing the "something" pipeline, the error
>handler of the pipeline containing the redirect-to is invoked.
>
>Now, in general this might be a good solution for internal pipeline
>calls when they are used in a map:generate etc., but it's imho
>a little unusal for a redirect.
>
>We had recently the discussion on this list, if we need a general
>solution to specify which error handler is used for internal pipeline
>calls. I discussed this a little bit with Vadim on IRC during our
>first friday and he suggest to specify this not on the caller but
>on the called pipeline. So the map:pipeline containing the
>"something" pipeline specifies what to do. Regardless if this is
>the better choice than specifying it in the uri ("cocoon:...."),
>it's technically nearly impossible. When the internal pipeline
>is called, everything happens outside the treehandler and there is
>no real chance to get the error handler etc. (Of course we could
>change something here and there and then it will work.)
>
>So, I just tried the other way:
><map:redirect-to uri="cocoon://something?cocoon:forward=true"/>
>
>The current implementation I have can only be used for redirects,
>although it's fairly simple to extend it to be used in
>map:generate etc. as well.
>
>WDYT? Is this of general interest?
>
>
>
I am just thinking whether it'd be worth a separate protocol something
like forward://something ?
--
Unico