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 Wed, 09 May 2007 13:18:45 GMT
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.
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.

> 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.

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

Mime
View raw message