[Zope3-dev] Re: Does WebDAV work on X3 Beta1?

[Philipp von Weitershausen]

Joachim Werner wrote:
>> a) you can file collector issues (to the Zope3-dev collector)
> 
> True. But in Zope 2 times one usually asked on the list first. This 
> might be a bug or just a configuration issue. So why should I file a 
> collector issue first?

Because an KeyError raised clearly is a bug. I would maybe count a
ComponentLookupError into configuration issues, but definitely not an
error like that.

>> b) an error is worth very little without a traceback
> 
> Sorry. Here it is:
> 
> 2004-06-30T11:43:57 ERROR SiteError http://gozinto:8080
> Traceback (most recent call last):
>   File "/opt/ZopeX3/lib64/python/zope/publisher/publish.py", line 138, 
> in publish
>     result = publication.callObject(request, object)
>   File "/opt/ZopeX3/lib64/python/zope/app/publication/http.py", line 41, 
> in callObject
>     return mapply(ob, request.getPositionalArguments(), request)
>   File "/opt/ZopeX3/lib64/python/zope/publisher/publish.py", line 113, 
> in mapply
>     return debug_call(object, args)
>   File "/opt/ZopeX3/lib64/python/zope/publisher/publish.py", line 119, 
> in debug_call
>     return object(*args)
>   File "/opt/ZopeX3/lib64/python/zope/app/dav/propfind.py", line 127, in 
> PROPFIND
>     names=avail.get(ns))
>   File "/opt/ZopeX3/lib64/python/zope/app/form/utility.py", line 141, in 
> setUpWidgets
>     for (name, field) in _fieldlist(names, schema):
>   File "/opt/ZopeX3/lib64/python/zope/app/form/utility.py", line 53, in 
> _fieldlist
>     fields = [ (name, schema[name]) for name in names ]
>   File "/opt/ZopeX3/lib64/python/zope/interface/interface.py", line 499, 
> in getDescriptionFor
>     raise KeyError, name
> KeyError: u'executable'
> 10.10.1.74 - zope.anybody [30/Jun/2004:11:43:57 +0200] "PROPFIND / 
> HTTP/1.1" 500 296 "" "Mozilla/5.0 (compatible; Konqueror/3.2; Linux) 
> (KHTML, like Gecko)"

I'm *pretty* sure that that is due to zope.app.dav.interfaces.IDAVSchema
lacking a schema field for 'executable'. The
zope.app.dav.adapter.DAVSchemaAdapter implements IDAVSchema and also has
an executable method, so I guess it's just a matter of adding this field
to one of the schemas that IDAVSchema derives from. Would anyone with
decent DAV knowledge know which one?

>> c) with a traceback, any developer with a bit of Python experience 
>> (which you certainly have) can track down the problem to a bit more 
>> specific issue, thus laying the ground work for those who go in and 
>> fix; and who knows, you might even end up fixing it yourself...
> 
> Well, this is not Zope 2. And in Zope X3 I don't have a clue how to 
> track down something like this (yet). I'll try anyway.

You can always point your editor to the files and take a look at the
source, or even better, use pdb to track things down.

I actually tried to reproduce your error and I couldn't. You didn't
really say WHAT exactly you did... Seems like you pointed Konqueror at
your Zope instance and I have no idea what kind of DAV commands
Konqueror issues. Maybe you can use Shane Hathaway's TCPWatch and give
us a more detailled explanation of what it was that your DAV client sent
and made Zope3 crash. We can then use that to write a test to ensure
this won't happen again.

Anyway, when I was trying to reproduce your problem, I stumbled upon a
different one. In my root folder, there's an object sitting that
*doesn't* provide IAnnotatable. For annotatable objects, the
zope.app.dublincore.annotatableadapter.ZDCAnnotatableAdapter is used to
feed dublincore metadata to DAV clients. For my object, it was
surprisingly finding an adapter, but obviously not that one. It found
zope.app.pagetemplate.talesapi.ZopeTalesAPI, which, too, tries to adapt
to IZopeDublinCore. If that fails (which it obviously does for my
non-annotatable object), it raises AttributeError.

So, I was getting an AttributeError for 'modified' when I tried to an
'ls' in cadaver. The problem lies in the following lines
(Zope3/src/zope/app/dav/adapter.py)::

      def getlastmodified(self):
         value = IDCTimes(self.context).modified
         if value is None:
             return ''

This code makes the assumption, that you can *always* get an adapter to
IDCTimes. ITALESAPI includes IDCTimes, that's why I got the ZopeTalesAPI
adapter for my object, which, however, raised an AttributeError because
my object wasn't annotatable after all...

So, we should probably

a) make the above code still work if IDCTimes adapter can't be found and

b) only register the ZopeTalesAPI adapter for annotatable objects

Comments?

Philipp


P.S.: I'm not an expert in DAV. I don't understand the tests well,
especially test_propfind. I see getlastmodified being used in
test_propfind, but it doesn't seem to be called. Fact is that we don't
test this behaviour at all right now.