jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: Regarding Webdav access
Date Wed, 14 May 2008 06:54:12 GMT
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
- check if the sequence of IOHandlers in WEBINF/config.xml is
- 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

View raw message