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
