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 11:50:59 GMT
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. :-(

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. 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.

Is it really neccessary or desirable to cache the mime-type? 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.

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?

Comments?

--
Unico


Mime
View raw message