Remy Maucherat wrote:
>
> > Hi all,
> >
> > I ran into a little problem earlier today.
> >
> > Basically, renaming a directory doesn't work. I'm not sure whether this
> > is a bug or a configuration error, though.
> >
> > The problem is this: the way my Domain.xml file is at the moment, the
> > basic directory structure (fairly complex) is created by slide at first
> > startup. However, we don't define any <revision> tags on the
> > directories. Is this wrong (i.e. are directories required to be
> > versioned like this?).
>
> One of the problem is that the XMLUnmarshaller doesn't do half of what it
> advertises at the moment. Basically, you can't create versioned resources
> during bootstrap, and you can't import content either.
True. It _does_ do all of what I'm trying to get it to do at the moment,
though.
> > I'll also note at this point that the example Domain.xml doesn't define
> > revisions on any of the directories it creates - but, on the other hand,
> > it only creates the root, and /users, /actions, and /files - none of
> > which would be expected to ever change.
>
> I'll look into the issue. I have a question : Does it break only with the
> objects created at bootstrap (like the "files" collection) ? It shouldn't
> break with "normal" collections or resources.
Objects (collections/directories) created later on seem to be created
with a revision if you use the webdav servlet (MKCOL method). I have
some other code that creates slide collections without going through the
webdav stuff, but that is based on the webdav servlet, so it does the
same.
I imagine (though I haven't tested) that XMLUnmarshaller will correctly
create a revision on the object if you explicitly tell it to - I don't
currently, and neither does the example Domain.xml file (with /files,
for example).
As a result, no - it doesn't break on colletions added later, but that's
solely because they're created differently. I see code elsewhere (webdav
servlet comes to mind) which checks explicitly for a collection by two
different methods - both by it not having revisions (like /files is),
and by it having a revision with a property resourcetype=<collection/>
This makes me think that it's deliberate (and hence that not having
revisions on collections is legal). If so, then it's a bug in
MacroImpl.java:copyObject(). My fix (which seems reasonable) is to put a
try/catch around lines 340-368 (rough line numbers - probably off by 1
or 2), and catch RevisionDescriptorNotFoundException. I have it log that
at the moment, but it's probably correct to silently catch it.
Michael
p.s. I found another couple of URL escaping/unescaping bugs in the
webdav stuff (one server side, one client side). I haven't actually
looked for where exactly they are, but I'll send a patch once I have.
Propfind can be considered broken on both ends until then (if anything
needs escaping, which is not always the case, of course).
