You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Gandhirajan Natarajan <Ga...@igate.com> on 2008/05/13 19:44:13 UTC

Regarding Webdav access

Hi,

 

Actually when we use jlibrary as our document management server, the
webdav functionality is working fine. (i.e. tiff files are getting
downloaded when we click on them in the browser)

 

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)

 

[AbstractExportContext] Result for IOHandler (DirListing Export): OK
------->   In jackrabbit (not working)

 

The only difference I could see is like; in the first case it calls
"org.apache.jackrabbit.server.io.DefaultHandler" and "DirListing Export"
in second case.

 

So what change I should do in the second case to make my webdav
functionality working as expected?? Please advice.

 

Thanks & Regards,

Gandhi Rajan.N

________________________________

| iSIGHT Development Team | iGATE Global Solutions| T: +91-80-4104 1312|
M: +91 9886834626 | gandhirajan.natarajan@igate.com |

| 158-162 & 165-170 EPIP Phase II Whitefield Bangalore - 560 066 India |
www.igate.com <http://www.igate.com/>  |

 

iGATE is Ranked No. 3 in DQ-IDC best IT employer survey and Ranked No.6 
by Business Today-Mercer Human Resource Consulting-TNS  in a cross industry survey of Best Companies to work for in India
----------------------------------------------------------------DISCLAIMER---------------------------------------------------------
Information transmitted by this EMAIL is proprietary to iGATE Group of Companies and is intended for use only by the individual 
or entity to whom it is addressed and may contain information that is privileged, confidential, or exempt from disclosure under 
applicable law. If you are not the intended recipient of this EMAIL immediately notify the sender at iGATE or mailadmin@igate.com 
and delete this EMAIL including any attachments

Re: Regarding Webdav access

Posted by Angela Schreiber <an...@day.com>.
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