cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Postable source and servlet services problem
Date Wed, 14 Feb 2007 23:04:17 GMT

I would like to start implementing postable source and special pipeline 
components supporting them; all leading to implementation of servlet 
services general concept. Before going into implementation details I 
would like to express my main concern.

Sitemap realization

Daniel proposed[1] postable source and bunch of special pipeline 
components calling servlet services. Let's focus only on transforming 
case as others (reading, generation and serialization) are similar or 
simpler cases. Now, we have to think about two main problems.

     Unnecessary serialization/deserialization
Daniel proposed[2] making servlet request and response objects 
SAX-aware. It's good idea, additionally we should provide fall back 
mechanism if target servlet was not SitemapServlet. Then stream of sax 
events should be seen as serialized into request body. In detail, we 
should conform with HTTP POST semantics. On the target sitemap side we 
would have pipeline like this:

<map:generate type="ServiceConsumer"/>
<map:transform type="..."/>
<map:transform type="..."/>
<map:serialize type="ServiceProducer"/>

If request is SAX-aware ServiceConsumer would just provide it's sax 
stream. If not, generator would try to parse request body (octet data) 
as XML and provide SAX stream. Service producer would work 
symmetrically. This way we could have generic servlet service pipeline 
without introducing new syntax into sitemap language. Also, we get fall 
back mechanism. I think it's really clean solution and non intrusive 
into any pipeline/sitemap code.

     Caching problems
That's really tricky part. Main problem is that ServiceConsumer has no 
information that could be used to calculate caching key. Caching key is 
unique (in component's context) identifier that identifies resource 
state (data) on processing stage. Normally generator provides some URI 
to the original resource or so. In our case, resource is SAX stream 
after some transformations applied. Thus, key must be an aggregation of 
the keys provided by components that applied some processing before 
service was called. Ok, so servlet service request should contain this 
aggregation (as ETag header or some request parameter). This is a right 
time to take a look on caller's sitemap:

<map:generate src="some.xml"/>
<map:transform type="service">
  <map:parameter name="service" 

We would like service transformer to pass cache key of generator to the 
request object created for calling the service. The problem is that 
AFAIK there is no way to obtain cache keys of the components that occur 
before any other component.

I think we hit here little design flaw. Transformer is atomic sitemap 
component, but servlet service is pipeline fragment. We try to treat 
pipeline as transformer and this leads to problems like outlined above. 
 From the user and elegance of the sitemap point of view it's justified 
to treat servlet service as exactly one transformer (or any other 
component) because it's aimed to hide any implementation details of the 
service and service really does the processing exactly the same 
(semantically) way as transformer. Even though it's technical problem, 
it *is* serious problem and I have to admit that have no idea how to fix 
it in a clever, clean way.

Comments? Thoughts?

Grzegorz Kossakowski

View raw message