Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <46459A08.2080500@nada.kth.se>
Date: Sat, 12 May 2007 12:42:16 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: More problems with implementing servlet services
References: <4640A55B.8070200@tuffmail.com> <46424753.1020005@nada.kth.se>
 <4643157E.10202@apache.org> <46446B88.5020607@nada.kth.se>
 <464488DA.9020008@apache.org> <4645832B.50406@nada.kth.se>
 <46458DAB.3030400@apache.org>
In-Reply-To: <46458DAB.3030400@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Grzegorz Kossakowski skrev:
> Daniel Fagerstrom napisał(a):
>> Grzegorz Kossakowski skrev:
>>> Daniel Fagerstrom napisał(a):
>>>
>>>
>>> Yes, we did. Here I'm talking about fall-back mechanism so called 
>>> servlet does not have to deal with SAX. The idea was to POST 
>>> serialized SAX stream in request body. However, this solution is 
>>> problematic if we have to merge that data with the one sent by browser.
>>>
>>> This fallback mechanism was to still stay compliant with standard 
>>> HTTP technique and adding SAX handling just for a sake of performance.
>>>
>>> WDYT?
>>
>> I agree.
> 
> Actually, I was asking about "problematic" part. ;-)
> In order to avoid unnecessary serializing of SAX buffer we could 
> implement lazy creation of request body so only if servlet asks for it 
> (becase it's dumb and does not handle SAX extension to the request 
> object) the serialization occurs. However, if original request contained 
> parts we must forward it. If called servlet tries to parse parts (only 
> to handle uploads) and already got SAX buffer we have no option to 
> serialize it because we need to return complete set of parts.
> 
> Do you have idea how to avoid this?

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

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.

Anyway I need some concrete example to get able to help with the 
"problematic" part.

>>> I'm not sure if I follow you here. Do you want to say that parts 
>>> parsing should work in lazy mode, so if caller of service does not 
>>> deal with parts double parsing is avoided, right?
>>
>> That would also be a possibility. I rather meant that instead of 
>> indiscriminately parsing all multi part mimes in a filter, the actual 
>> parsing should be done first in the servlet service that actually is 
>> intending to use the parts.
> 
> Right but we know if particular sitemap's servlet is going to use parts?

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.

/Daniel