Grzegorz Kossakowski skrev:
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.
When calling the servlet service source you are first creating a new
request and response object. The "request body" of the request object is
represented by the getInputStream method of the request object. For the
case above the request object created for the servlet service call will
contain the input stream from the FileSource that "somefile" is resolved to.
If you want to use the request body of the calling sitemap, you instead
would write:
<map:generate src="service-consumer:">
<map:parameter name="service" value="servlet:B:/service/some"/>
</map:generate>
In this case the service consumer source will give you a input stream
that represent the request body of the calling sitemap and that will
represent the request body of the new request object that you use for
calling the servlet service.
In the later case you just pass a input stream from the request object
of the caller to the request object of the callee. I don't see that any
parsing of the request body is involved at all, and even less, any
reparsing.
In your example the I don't see any reason why the called servlet
service should have any access to the request body of the calling
servlet service whatsoever.
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.
I think that the main thing to keep in mind is that when you are calling
as servlet service, you always build a new request and response object
that you use for the call.
Now, these new request and response object certainly can refer back to
the original request and response objects for reusing some info. But the
called servlet service should have *no* direct access to the original
request and response objects of the caller.
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?
The idea in my view about multi part mime parsing was that it is done in
e.g. an action in the pipeline that needs the parts. So in your example
the A pipeline would need to have a parsing action that is executed
before the calling of the B servlet service. And in such a case I wonder
if it would not be more natural to call have a service that just handle
a part of the multi part mime through e.g. the parts source. In this
case the B service would not need to know anything about multi part
mimes at all.
If we really have some use case where both the caller and the callee
need to have access the original multi part mime, then you would need
some reparsing. But the example seem rather unlikely for me, so I don't
think we need to care about it. And if we need to care about it it
shouldn't be that complicated to find out some mechanism for solving it.
/Daniel
