cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [cocoon-2.2] Deprecation
Date Wed, 07 Nov 2007 22:19:02 GMT
Carsten Ziegeler pisze:
> Hmm, no, I don't think so :(
> I think most of the relevant code is in the SitemapHelper class.

Thanks, I'll have a look.

>> Is the context really changed for each sax events? I thought that cocoon: protocol
creates some kind
>> of derived environment for each cocoon: call and this way (some) separation is assured.
>>
>> Can you point me to relevant place?
> It's in the SitemapSource. There is a special sax event wrapper which is
> placed around the receiving sax handler:
>     EnvironmentHelper.createEnvironmentAwareConsumer(consumer)
> So for each sax event the environment is changed back and forth.

You are right. Argh, SitemapSource is even more complicated than I thought...

>> I agree. The servlet: protocol does buffering but it does something more: it serializes
and parsers
>> XML each time servlet request is made. This really affects performance and must be
changed but it's
>> not that hard and the change would limited to only cocoon-servlet-* modules.
> Yepp, I think we should support the extensions of the
> HttpServletResponse which we discussed
> a long time ago and which can be found in the processor module of our
> whiteboard.
> The buffering could be a recording of sax events with the sax buffer.

I was discussing very similar idea with Leszek at GT and he expressed interest in implementing
such
behaviour for respone/request classes used by servlet protocol. Leszek, do you still plan
to
implement this in a foresable future?

When it comes to the request being SAX aware there is a small problem. There was a common
agreement
that we should implement fall-back mechanism in case that called servlet does not support
SAX-aware
request/response combo. The fall-back mechanism would work the way as reqest/reponse classes
work
now so the incoming SAX stream is serialized into request's body and produced SAX stream is
serialized to response's body. However, at the same time we agreed that we would like to forward
request data (including parameters, uploaded files) from original request. Then there is a
clash
between data coming from SAX events and uploaded files that must be included in the same request
body. I don't know any good solution for this problem apart from encoding serialized SAX stream
as
another uploaded file.

Any ideas on this?

-- 
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message