You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Ralph Goers <ra...@dslextreme.com> on 2009/02/12 21:50:46 UTC
WebDAV
I am trying to access jackrabbit via WebDav for enhancements to
commons-vfs and commons-configuration. I have had several issues with
WebDAV not working properly but the most frustrating one at the moment
is in trying to store XML files.
First, I am actually using CRX which is nothing but a thin veneer
around Jackrabbit (as many of you know since you work for Day). When I
store an XML file to the default workspace using http://localhost:
7402/ the file gets stored under jcr:content which has a type of
nt:unstructured. Retrieving the file works properly.
When I create my own workspace or just use http://localhost:7402/crx/repository/crx.default
(the same default workspace) attempts to store xml files cause the
jcr:content to be stored as type crx:XmlDocument. Doing an ls on the
directory in cadaver shows the file name and a 404 File Not Found.
Looking at these files on Windows shows them to be of zero length.
So does anyone know how I configure the Webdav servlet so that it has
the correct behavior (nt:unstructured)?
Thanks.
Ralph
Re: WebDAV
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 12, 2009, at 2:04 PM, Alexander Klimetschek wrote:
> Hi,
>
> actually this question would be something for the official crx mailing
> list at Yahoo [1]. But see my answers inline below:
Yeah, I know. But I figured this would be faster. And from what I can
tell your answer applies beyond just CRX (which isn't much of a
surprise).
>>
>
> The webdav implementation in Jackrabbit and CRX is extendable through
> IO Managers [2] and IO handlers [3], that can do custom import/export
> over webdav. A manager is simply a collection of handlers, and each
> handler typically handles a specific file format. For example, the
> XMLHandler, that is by default enabled in CRX, stores XML natively in
> a crx:XmlDocument node (and subtree representing the inner XML)
> instead of a binary nt:file [4].
>
> The XMLHandler is triggered by mime-type, so it should only happen if
> the webdav request that sends the file includes the "text/xml" mime
> type. If you set it to application/octet-stream (that standard binary
> mimetype), the xml file should be stored as nt:file.
>
> Otherwise, you could also change the IO Manager configuration, it's
> inside WEB-INF/config.xml. Commenting out the CrxDefaultIOManager
> should do the trick - I don't know if there must be an IO manager
> specified. You might want to take a look at the default config.xml
> that comes with the Jackrabbit webapplication [5].
Thanks. If I understand correctly then I should file a bug report with
Day since the CRXDefaultIOManager publishes xml documents in such a
way that they cannot be read by "standard" webdav applications? I
would expect that even if the documents get stored as crx:XmlDocument
that a webdav get should be able to retrieve the document instead of
returning a 404 error - or a file length of 0.
Ralph
Re: WebDAV
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 13, 2009, at 7:50 AM, Jukka Zitting wrote:
> Hi,
>
> On Fri, Feb 13, 2009 at 4:25 PM, Ralph Goers <ralph.goers@dslextreme.com
> > wrote:
>> I don't think the problems I am having are related to CRX
>> extensions. As I
>> said, http://localhost:7402/ is the url that isn't having these
>> problems. It
>> is when I use the full path to the repository that WebDAV is
>> broken. As I
>> understand it, that configuraton uses only the Jackrabbit webdav
>> servlet.
>
> Can you reproduce the problem using the Jackrabbit standalone server?
>
>
I haven't tried. Installing CRX 1.4.0 quickstart was dirt simple and
is what my employer will be using. But I'll see what I can do to set
up jackrabbit by itself and try it over the weekend.
Ralph
Re: WebDAV
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Feb 13, 2009 at 4:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> I don't think the problems I am having are related to CRX extensions. As I
> said, http://localhost:7402/ is the url that isn't having these problems. It
> is when I use the full path to the repository that WebDAV is broken. As I
> understand it, that configuraton uses only the Jackrabbit webdav servlet.
Can you reproduce the problem using the Jackrabbit standalone server?
BR,
Jukka Zitting
Re: WebDAV
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Feb 17, 2009 at 4:29 PM, Angela Schreiber <an...@day.com> wrote:
>> We probably should do the same in Jackrabbit and remove the XmlHandler
>> from the webapplication's config.xml [1] (or just comment it out).
>
> -1
?
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebDAV
Posted by Angela Schreiber <an...@day.com>.
> We probably should do the same in Jackrabbit and remove the XmlHandler
> from the webapplication's config.xml [1] (or just comment it out).
>
> WDYT?
-1
angela
Re: WebDAV
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Feb 17, 2009 at 3:52 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> Thanks. So it really is a CRX issue. They have reproduced the problem.
It's not a bug, but rather a not-so-practical default configuration.
AFAIK the XmlHandler is going to be removed from the default config.
We probably should do the same in Jackrabbit and remove the XmlHandler
from the webapplication's config.xml [1] (or just comment it out).
WDYT?
[1] https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-webapp/src/main/webapp/WEB-INF/config.xml
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebDAV
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Feb 17, 2009 at 3:52 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> So it really is a CRX issue.
So you've just wasted the time of all the Jackrabbit users here who've
been following this thread.
In future, please use the correct support channels for the product
you're using. This mailing list is for discussing use of Apache
Jackrabbit, not other products based on Jackrabbit.
BR,
Jukka Zitting
Re: WebDAV
Posted by Ralph Goers <ra...@dslextreme.com>.
Thanks. So it really is a CRX issue. They have reproduced the problem.
Ralph
On Feb 17, 2009, at 2:22 AM, Alexander Klimetschek wrote:
> On Fri, Feb 13, 2009 at 4:25 PM, Ralph Goers <ralph.goers@dslextreme.com
> > wrote:
>> I don't think the problems I am having are related to CRX
>> extensions. As I
>> said, http://localhost:7402/ is the url that isn't having these
>> problems. It
>> is when I use the full path to the repository that WebDAV is
>> broken. As I
>> understand it, that configuraton uses only the Jackrabbit webdav
>> servlet.
>
> No, the one at http://localhost:7402/ is Sling's WebDAV, which uses
> the standard Jackrabbit SimpleWebdavServlet plus the following
> configuration, which does *not* include the aforementioned XMLHandler:
>
> https://svn.eu.apache.org/viewvc/incubator/sling/tags/org.apache.sling.jcr.webdav-2.0.2-incubator/src/main/resources/webdav-resource-config.xml?view=markup
>
> The webdav endpoint at http://localhost:7402/crx/repository uses CRX'
> standard config.xml, which includes the CrxIOManager that (in the code
> rather than in the config.xml) includes the XMLHandler. You could
> simply stop CRX, go to the config.xml (in the
> server/runtime/0/_crx/WEB-INF directory) and replace the
> com.day.crx.io.CRXIOManager with
> org.apache.jackrabbit.server.io.DefaultHandler, which should turn off
> the XMLHandler.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
Re: WebDAV
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Feb 13, 2009 at 4:25 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> I don't think the problems I am having are related to CRX extensions. As I
> said, http://localhost:7402/ is the url that isn't having these problems. It
> is when I use the full path to the repository that WebDAV is broken. As I
> understand it, that configuraton uses only the Jackrabbit webdav servlet.
No, the one at http://localhost:7402/ is Sling's WebDAV, which uses
the standard Jackrabbit SimpleWebdavServlet plus the following
configuration, which does *not* include the aforementioned XMLHandler:
https://svn.eu.apache.org/viewvc/incubator/sling/tags/org.apache.sling.jcr.webdav-2.0.2-incubator/src/main/resources/webdav-resource-config.xml?view=markup
The webdav endpoint at http://localhost:7402/crx/repository uses CRX'
standard config.xml, which includes the CrxIOManager that (in the code
rather than in the config.xml) includes the XMLHandler. You could
simply stop CRX, go to the config.xml (in the
server/runtime/0/_crx/WEB-INF directory) and replace the
com.day.crx.io.CRXIOManager with
org.apache.jackrabbit.server.io.DefaultHandler, which should turn off
the XMLHandler.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebDAV
Posted by Ralph Goers <ra...@dslextreme.com>.
I don't think the problems I am having are related to CRX extensions.
As I said, http://localhost:7402/ is the url that isn't having these
problems. It is when I use the full path to the repository that WebDAV
is broken. As I understand it, that configuraton uses only the
Jackrabbit webdav servlet.
Ralph
On Feb 12, 2009, at 11:59 PM, Angela Schreiber wrote:
>
>> Please note that the WebDAV exposed at the root of your CRX
>> (http://localhost:7402/) is provided by Sling, which is a different
>> WebDAV implementation
>
> as far as i know Sling uses an extension of the
> simple webdav servlet known from jackrabbit. it has
> its own locator factory, session provider and config.
>
> i wouldn't call this a different WebDAV implementation.
>
> >> When I create my own workspace or just use
> >> http://localhost:7402/crx/repository/crx.default
>
> this one isn't the sling serlvet but a day specific
> extension of the jackrabbit webdav servlet.
>
> nevertheless: if you experience your problem with the
> jackrabbit webdav implementation feel free to post them here.
>
> if it *only* occurs with CRX please direct yourself
> to the mentioned yahoo group or get support from
> day directly. this isn't the right channel to post
> questions regarding CRX.
>
> regards
> angela
Re: WebDAV
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Feb 13, 2009 at 8:59 AM, Angela Schreiber <an...@day.com> wrote:
> as far as i know Sling uses an extension of the
> simple webdav servlet known from jackrabbit. it has
> its own locator factory, session provider and config.
>
> i wouldn't call this a different WebDAV implementation.
Yes, implementation was the wrong term. I wanted to say that this is a
different WebDAV server endpoint or servlet than the crx/repository
one.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebDAV
Posted by Angela Schreiber <an...@day.com>.
> Please note that the WebDAV exposed at the root of your CRX
> (http://localhost:7402/) is provided by Sling, which is a different
> WebDAV implementation
as far as i know Sling uses an extension of the
simple webdav servlet known from jackrabbit. it has
its own locator factory, session provider and config.
i wouldn't call this a different WebDAV implementation.
>> When I create my own workspace or just use
>> http://localhost:7402/crx/repository/crx.default
this one isn't the sling serlvet but a day specific
extension of the jackrabbit webdav servlet.
nevertheless: if you experience your problem with the
jackrabbit webdav implementation feel free to post them here.
if it *only* occurs with CRX please direct yourself
to the mentioned yahoo group or get support from
day directly. this isn't the right channel to post
questions regarding CRX.
regards
angela
Re: WebDAV
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 12, 2009, at 2:21 PM, Alexander Klimetschek wrote:
> On Thu, Feb 12, 2009 at 11:19 PM, Ralph Goers
> <ra...@dslextreme.com> wrote:
>> Also, do you have any idea how to do this in Mac OS's Finder,
>> cadaver or
>> DAVExplorer?
>
> I use the Mac OS built-in WebDAV client with CRX and it does not send
> text/xml mimetypes, so it works basically as a normal file system.
> AFAIK most webdav clients, especially the filesystem-mounting ones, do
> not set any "advanced" mime types in their request.
>
I'm confused. Are you saying that I should not be seeing the problem I
am experiencing?
Actually, the problem is even more interesting. I connected to the
server via Finder and then copied a single XML file and pasted it to
the repository. It worked fine. I then selected about 30 files and
pasted them all to the repository. At that point all the XML files in
the target directory, including the one previously copied, couldn't be
read. So I started doing them 1 by 1. Things looked fine after doing 5
or 6, but then I went back to the first file I had copied. Although
the file size was right, opening it in an editor showed no content. As
I continued to do this I'd notice the same thing. Then I went back to
the latest file and viewed its contents again and it too had no
content. I went to cadaver and did an ls. Sure enough, they all had
file sizes but when I'd do a get I would end up with an empty file.
So then I went into content explorer and got different results than
previously. Now the jcr:content is nt:resource, jcr:mimeType is text/
xml and the jcr:data is binary with a non-zero (and correct) length.
And yet, retrieving the file results in a file with zero length.
Ralph
Re: WebDAV
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Feb 12, 2009 at 11:19 PM, Ralph Goers
<ra...@dslextreme.com> wrote:
> Also, do you have any idea how to do this in Mac OS's Finder, cadaver or
> DAVExplorer?
I use the Mac OS built-in WebDAV client with CRX and it does not send
text/xml mimetypes, so it works basically as a normal file system.
AFAIK most webdav clients, especially the filesystem-mounting ones, do
not set any "advanced" mime types in their request.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: WebDAV
Posted by Ralph Goers <ra...@dslextreme.com>.
On Feb 12, 2009, at 2:04 PM, Alexander Klimetschek wrote:
>
>
> The XMLHandler is triggered by mime-type, so it should only happen if
> the webdav request that sends the file includes the "text/xml" mime
> type. If you set it to application/octet-stream (that standard binary
> mimetype), the xml file should be stored as nt:file.
>
Also, do you have any idea how to do this in Mac OS's Finder, cadaver
or DAVExplorer?
Ralph
Re: WebDAV
Posted by Alexander Klimetschek <ak...@day.com>.
Hi,
actually this question would be something for the official crx mailing
list at Yahoo [1]. But see my answers inline below:
On Thu, Feb 12, 2009 at 9:50 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> First, I am actually using CRX which is nothing but a thin veneer around
> Jackrabbit (as many of you know since you work for Day). When I store an XML
> file to the default workspace using http://localhost:7402/ the file gets
> stored under jcr:content which has a type of nt:unstructured. Retrieving the
> file works properly.
Please note that the WebDAV exposed at the root of your CRX
(http://localhost:7402/) is provided by Sling, which is a different
WebDAV implementation than the standard Jackrabbit/CRX webdav at
http://localhost:7402/crx/repository/<workspace-name>. It doesn't have
those options mentioned below. That it creates nt:unstructured below
nt:file can be a bit cumbersome, normally one would expect an
"nt:resource" for the jcr:content node (it's not forbidden by the
nt:file node type, but one has to be aware of that). Therefore it is
sometimes better to use the CRX webdav (once you got it working for
your needs ;-)).
> When I create my own workspace or just use
> http://localhost:7402/crx/repository/crx.default (the same default
> workspace) attempts to store xml files cause the jcr:content to be stored as
> type crx:XmlDocument. Doing an ls on the directory in cadaver shows the file
> name and a 404 File Not Found. Looking at these files on Windows shows them
> to be of zero length.
>
> So does anyone know how I configure the Webdav servlet so that it has the
> correct behavior (nt:unstructured)?
The webdav implementation in Jackrabbit and CRX is extendable through
IO Managers [2] and IO handlers [3], that can do custom import/export
over webdav. A manager is simply a collection of handlers, and each
handler typically handles a specific file format. For example, the
XMLHandler, that is by default enabled in CRX, stores XML natively in
a crx:XmlDocument node (and subtree representing the inner XML)
instead of a binary nt:file [4].
The XMLHandler is triggered by mime-type, so it should only happen if
the webdav request that sends the file includes the "text/xml" mime
type. If you set it to application/octet-stream (that standard binary
mimetype), the xml file should be stored as nt:file.
Otherwise, you could also change the IO Manager configuration, it's
inside WEB-INF/config.xml. Commenting out the CrxDefaultIOManager
should do the trick - I don't know if there must be an IO manager
specified. You might want to take a look at the default config.xml
that comes with the Jackrabbit webapplication [5].
[1] http://groups.yahoo.com/group/jcr-crx/summary
[2] http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/server/io/IOManager.html
[3] http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/server/io/IOHandler.html
[4] http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/server/io/XmlHandler.html
[5] https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-webapp/src/main/webapp/WEB-INF/config.xml
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com