Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4718D299.9050908@day.com>
Date: Fri, 19 Oct 2007 17:51:53 +0200
From: Angela Schreiber <anchela@day.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: WebDAV: nt:file question
References: <1192804838.3592.252.camel@bslm-046.corp.day.com>
	 <4718CC84.2070909@day.com> <1192807866.3592.258.camel@bslm-046.corp.day.com>
In-Reply-To: <1192807866.3592.258.camel@bslm-046.corp.day.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hi felix

> Thanks a lot for the informations. Helps alot and of course I do not
> want to change the defualt behaviour, 

oc...

> though I think they are wrong in
> terms of JCR, but this is MHO and nothing more :-)

oh, it's not wrong in terms of JCR. please note the definition
of the nt:file nodetype being

[nt:file] > nt:hierarchyNode
   + jcr:content (nt:base) primary mandatory

just out of curiosity: did you have a webDAV problem with
the nt:unstructured node or was it rather another application
accessing the nt:file node and (obviously) ignoring the
logic applied by the various handlers?

this application may also have a problem with the way
e.g. the ZipHandler stores a zip-file: it creates a
unstructured jcr:content node and extracts contents
of the zip-file building folders and files underneath
the jcr:content node, rather than writing a single
binary data property (primary item). right?

regards
angela