cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: More problems with implementing servlet services
Date Fri, 18 May 2007 12:30:34 GMT
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
> 
> I don't see where the problem you describe would occur. Could you please 
> give an concrete example of it.
> 
> AFAICS there are two main cases. First case is that you call a servlet 
> service from a reader (or generator) in a sitemap e.g.:
> 
> <map:read type="servletService">
>   <map:parameter name="service" value="servlet:test:/service"/>
> </map:read>
> 
> This is essentially a redirection. In this case you just pass on the 
> unparsed request body from the caller to the callee. Typically the 
> calling servlet will just have used read access from the header of the 
> http request in order to execute matchers and selectors. In this case 
> the request body could as an example be an unparsed multi part mime or 
> an unparsed XML document that the callee then takes responsibility to parse

Right, but how about following situation when we have:
<map:generate src="somefile">
   <map:parameter name="service" value="servlet:B:/service/some"/>
</map:generate>

Original request body cannot be passed to the called service untouched because we also have
to pass data of somefile in request body. I was 
thinking about putting "somefile" data as another part but this surely requires parsing original
parts, adding one more and serializing 
everything back to the request body of service call request.

I wonder how to avoid it.

> The second case is that you call a servlet service transformer (or 
> serializer). In this the generator of the caller pipeline (or an action 
> or a flowscript) will already have done the parsing needed of the 
> request body and then transformed it to whatever XML format that the 
> called servlet service is supposed to use as input (request body). I 
> don't see why the called servlet service should need to have access to 
> the callers request body in this situation.

I'm not sure if service should have access to the request body either (cannot give convincing
example for now) but I think that such an 
asymmetry would be at least confusing if not limiting in some cases.

> If we do the actual parsing in e.g. an action within a sitemap instead 
> of in a filter, we don't need to know.

What if servlet A calls service of servlet B, B parsers parts and does its job but after returning
to the A's pipeline it turns out that it 
also needs access to the parts. Will they get reparsed?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message