cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: More problems with implementing servlet services
Date Fri, 11 May 2007 13:11:36 GMT
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>> Looking at the AbstractProcessingPipeline the getMimeType method of 
>> the serializer is called from the setMimeTypeForSerializer method 
>> that in turn is called in the beginning of the processXMLPipeline 
>> method *before* the generator.generate() method that lead to the 
>> actual execution of the serializer. I might be missing something, but 
>> AFAICS the call of the setMimeTypeForSerializer method call could be 
>> moved to *after* the generator.generate call without changing the 
>> result at all.
> This will work only if output stream of Http response is buffered so 
> nothing is sent to the browser before setMimeTypeForSerializer is 
> called. Is it always the case?
As Vadim notes, it is not allways the case.

So I'm afraid that we are back at your original proposal, which as Vadim 
noted has some other problems :/

>> That would make the servlet-service-impl dependent on 
>> cocoon-pipeline-api, which I wouldn't like at all. The idea with the 
>> servlet service stuff is that it should be independent of the rest of 
>> Cocoon.
> Yes, I agree with idea and would like to violate its independence and 
> that's why I seek for other solution.
>> First I wonder why the forms frame work depend on Environment 
>> specific things and not just what is present in the standard http 
>> request object.
> After sleeping with a problem in mind I guess that situation is not 
> such dramatic and you can be probably right that passing only request 
> data is enough.
> However, if pass for example uploaded files sent by browser we need to 
> think about:
> 1. Passing an XML stream serialized and encoded in request body, along 
> with data sent by browser
This is something we have discussed before isn't it? The main idea is to 
extend the request and response object with some sax handling APIs.
> 2. Avoiding reparsing again and again input data sent by browser
> I really see both points quite troublesome. For first one, I guess we 
> would have to encoded that stream as yet another file the same way as 
> browser encodes multiple uploads.
> Any thoughts, hints?
For the multi part mime parsing that is used for e.g. uploads, the main 
problem is the way that this typically is handled in servlet based 
webapps. I.e. that all multi part mimes are handled already in a filter 
that is used before the servlet. In Cocoon it would be more natural to 
do multi part mime handling in the sitemap so that different things can 
be done for different URLs. Also the mime type handling could be 
deferred to the actual servlet service that is going to use it instead 
of doing it in front of the main servlet.

One could also consider havĂ­ng servlet service specific filter chains. 
This could be implemented with Spring interceptors that are added to a 
servlet service and intercepts the servlet calls.

>> But if we leave that for the moment I think that the best way to pass 
>> information (e.g. request, response and maybe environment object) in 
>> the call chain in an unintrusive way is by using a call stack. I 
>> implemented a fairly generic call stack in o.a.c.callstack in the 
>> cocoon-servlet-service module. It also provide a custom 
>> Springframework call scope (see 

>> about custom scopes) that makes it possible to get the "current" 
>> environment object through ordinary dependency injection.
>> The call stack o.a.c.environment.internal.EnvironmentStack in 
>> cocoon-sitemap-impl is used internally in the sitemap for passing 
>> environment info to e.g. subsitemaps and Cocoon calls. By refactoring 
>> it so that it used the o.a.c.callstack stuff internally, we could 
>> have a common callstack both for block calls and sitemap internal 
>> calls. Then environment info and other servlet specific info could be 
>> passed in an unintrusive way.
> Certainly, this functionality would be useful but I fear that it would 
> take me a lot of time to do it properly. Any chance that you will be 
> able to help in foresable future?
That is my intention.


View raw message