cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: svn commit: rev 55619 - in cocoon/branches/BRANCH_2_1_X/src: test/anteater webapp/samples/test/reader-mime-type
Date Wed, 27 Oct 2004 17:19:26 GMT
Vadim Gritsenko wrote:

> Unico Hommes wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Unico Hommes wrote:
>>>
>>>> Now only one release blocker remains: NPE in 
>>>> AbstractEnvironment.release()
>>>
>>>
>>>
>>> No, not exactly. As I see it, ResourceReader should return Source's 
>>> mimeType in this particular case, as per:
>>>
>>>     public String getMimeType() {
>>>         Context ctx = ObjectModelHelper.getContext(objectModel);
>>>         if (ctx != null) {
>>>             final String mimeType = ctx.getMimeType(source);
>>>             if (mimeType != null) {
>>>                 return mimeType;
>>>             }
>>>         }
>>>
>>>         return inputSource.getMimeType();
>>>     }
>>>
>>> But in this case, it was not able to get mime type of the 
>>> SitemapSource. SitemapSource, in its turn, was retrieving mimeType 
>>> from the environment:
>>>
>>> 344:                this.mimeType = this.environment.getContentType();
>>>
>>> But for some reason it is not there. I think that is the problem and 
>>> it was a valid test case for this problem. Unless I am mistaken... 
>>> If I'm not, we should revert the removal of test case.
>>
>>
>>
>>
>> No don't say that! I thought we'd finally gotten rid it. :-(
>
>
> Ooops. I'm sorry! :)
>
>

Never mind. It's not your fault ;-)

>> You are right though. My conclusion that the test case was no longer 
>> valid was premature. It used to be that SitemapSource would just 
>> return hard-coded text/xml as its mime type.
>>
>> Anyway, the problem appears to be that the mime-type is only set on 
>> the environment by the processing pipeline during actual processing 
>> whereas at the time Reader.getMimeType is called the pipeline has 
>> only been setup and prepared.
>>
>> Now I am wondering whether we can move setting the mime-type from the 
>> processing stage to the preparation stage.
>
>
> Probably we should, if possible. 


I should be possible if the issue Luigi raised doesn't hold valid. 
Should the data stream in the pipeline have any say over its own 
characteristics? I am not sure. It would be a whole lot easier if we 
would just mandate it. But then perhaps the Response.setHeader should 
not even be available to sitemap components, or FOM even. Hmm.

>
>> The reason it is currently being done during processing is that in 
>> the case of the caching pipeline the mime-type is held in the cached 
>> response and the retrieval of the cached response is delayed until 
>> the processing stage in order to optimize performance.
>
>
> If mime-type is always set during pipeline setup, it will be not 
> necessary to store it in the cached response at all. Moreover, current 
> situation is flawed anyway: what about all the other headers? They are 
> all lost on second request. If all headers are set during pipeline 
> setup, we won't have the issue.

>> Is it really neccessary or desirable to cache the mime-type?
>
>
> See above.
>
>
>> What happens if the effective mime-type is from the  one from the 
>> reader definition or the read node declaration (<map:reader 
>> class=".." mime-type="text/xml"/> or <map:read src="somewhere" 
>> mime-type="text/xml" />) From these examples it follows that the 
>> mime-type must be part of the cache-key because if you were to change 
>> it in any of the attributes above the previously cached contents 
>> should not be served.
>
>
> Not if it set as described above.
>
>
>> Btw. ResourceReader.getMimeType() method above looks a bit funny to 
>> me. The mime-type mapping from the context has priority over the 
>> mime-type of the individual source. Surely that should be the other 
>> way around?
>
>
> There were some changes around mime type handling in 2.2...
> http://issues.apache.org/bugzilla/show_bug.cgi?id=10277
>
> ResourceReader implementation was not changed, though.


Yes, the conclusion at the end seems not to match the code in 
ResourceReader.

--
Unico



Mime
View raw message