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
