On Wed, 27 Oct 2004, 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. :-(
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.
I would like to consider allowing the mime-type to be set during processing, perhaps even as late as after endDocument(). The reason for this is: I store images in XML documents as Base64 encoded data, and its element tag looks like this:
<image mime-type="image/png">Base64data</image>
In this way I can store any kind of image in my files, and it is extracted correctly (I have a Base64Serializer to stream it out). However, in order to correctly extract it, I have to know, in the sitemap, /a priori/, what the mime-type is. Which leads to ugly hacks such as: "You can only put PNG images in this document and JPG images in this document, so I know how to extract them", or perhaps the requester would have to know to ask for a particular mime-type. And adding support for a new image type (admittely this does not happen frequently!) means updating the sitemap and adding new "rules". If I could set the mime-type of the response at least after the pertinent startElement(), then I'd be fine. Of course, that would mean that the response couldn't start streaming until it was "complete" - in this case, setting the mime-type might be the last thing it needs before beginning the stream.
What would this mean for caching? For me, it means the mime-type *cannot* be part of the cache-key, since it cannot be known a priori. However, it does have to be cached with the document.
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
