hi gandhirajan
Now we are trying to use jackrabbit as our document management server. In this case when we try to access the tiff files via webdav, they are not getting downloaded as mentioned in the mails earlier.
The log info of the webdav access on both the scenario is as follows
[AbstractExportContext] Result for IOHandler *(org.apache.jackrabbit.server.io.DefaultHandler*): OK --- à In jlibrary (working fine)
sounds reasonable the DefaultHandler is the one that handles any kind of files.
[AbstractExportContext] Result for IOHandler *(DirListing Export)*: OK ----- à In jackrabbit (not working)
yes. because the DirListingExportHandler should only deal with nt:folder and unknown nodetypes. so. it surprises me a bit, that the DirListingExportHandler takes over as IOHandler for your nt:file node (the tiff image). there used to be an issue with the DirListingExportHandler but that only affected PROPFIND but not GET. see -> http://issues.apache.org/jira/browse/JCR-1364 so, i don't expect this to be the source of problem in your case. as your node structure with tiffs works fine for me, you could do is the following: - check the WEBINF/config.xml: do you specify a custom IOManager/PropertyManager? - check if the sequence of IOHandlers in WEBINF/config.xml is correct. - check if the <nodetypes> configuration entry in the same config.xml does not list nt:file as 'directory' nodetype. if it doesn't help: - comment the DirListingExportHandler from the sequence of PropertyHandlers (same config.xml) - comment the DirListingExportHandler from the sequence of IOHandlers(same config.xml) and in order to provide feedback to the list, it would be cool if you had time to step through the IOHandler processing and find out, why DirListingExportHandler wants to be responsible for an nt:file node. this should not be the case. hope that helps angela
