cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: More problems with implementing servlet services
Date Wed, 09 May 2007 13:27:50 GMT
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.


Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message