Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
<snip/>
What do you think?
IIUC there are two use cases for servlet services: They can be used
from within Cocoon using special sitemap components or from outside
using the http protocol. Whatever the best solution for passing
environment data is, is it possible to support both scenarios?
Actually, HTTP protocol is always used in service calls but components
just hide low-level details of HTTP and integrate calls with pipelining
model. In current (and basic) state of implementation one could call
services remotely because all data is carried using standard HTTP
methods like headers and POST request method with data encoded in
request body.
I hardly see how this could be achieved with whole environment, the only
option would be to serialize it to the byte stream and send it as POST
too. However, I guess that even if it was technically possible it would
be very impractical.
It's important to realize that you still can pass portion of environment
data that service really needs using for example posted XML or http
headers/parameters. For small, focused services implemented by simple
servlets usually it will be enough.
This fallback mechanism is what I was asking for and good enough.
Problem arises only when you make a call from Cocoon's sitemap servlet
to another Cocoon's sitemap servlet that can make use of all goodies we
have, especially, flowscript.
I feel that passing whole env. via request object not using HTTP methods
is kind of hack but I have no other idea and I guess only Cocoon
servlets are those who are going to make a use of whole env, anyway.
As long as the fallback mechanism as described by you above works, I don't see a
problem with your solution.
The same probably applies to using a SAX buffer instead of using byte
streams that require time-consuming serialization and deserialization
but using byte streams as the lowest common denominator should be
supported for non-Cocoon requests.
Yes, you are right, here. I was thinking about passing SAX buffer and
implementing fall-back mechanism in CallBlockHttpRequest so if some dumb
servlet calls getInputStream() method instead of obtaining SAX buffer
from the CallBlockHttpRequest object it's feeded with serialized XML.
The same applies for output stream and CallBlockHttpResponse. This way,
you can still integrate SAX-not-aware servlets very easily and
serialization is done in lazy way.
great
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
