cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] Forwarding of internal pipeline calls
Date Mon, 08 Mar 2004 15:38:07 GMT
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 }


Mime
View raw message