You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <oz...@c1-fse.de> on 2003/08/20 13:01:14 UTC

BUG in StructureImpl/ObjectNode?

Hi,

there seems to be a bug in org.apache.slide.structure.StructureImpl and 
also in org.apache.slide.structure.ObjectNode introduced by your changes.

Symptoms: When creating objects from the data part of the Domain.xml 
file that are already there, they are not linked to the root collection 
"/".

I analyzed the code a bit and found two *possibly* erroneous spots:
- in StructureImpl.create you should check if something is an object 
directly under the root collection, instead you check for the root 
collection itself
- adding children to the root collection using addChild in ObjectNode 
may lead to double leading slashes, e.g. //files

I also added a patch which surely is not most elegant, but is rather 
intended to make my point clearer. Anyway, after applying it here 
everything seemed to work ok.

Thanks for caring,
Oliver

Nevermann, Dr., Peter wrote:

> Hi Sliders,
> 
> we have been working on adding support for Binding in Slide (server) and I
> just checked-in a bunch of changes. The main part comes in the class
> org.apache.slide.structure.ObjectNode.java. For the specification of the
> WebDAV Binding Extension see http://www.webdav.org/bind/. 
> 
> There are 2 switches for enabling/disabling binding: a global one (property
> org.apache.slide.binding in slide.properties) and one at store level (method
> useBinding() in org.apache.slide.store.Store.java).
> Both switches are currently *disabled* by default ... so everything should
> work as before if you do not explicitly enable binding.
> 
> To make use of the binding extensions it is *not* enough to switch-on
> binding. The store implementation must be adapated to become
> binding-enabled. Roughly speaking, a binding-enabled store implementation
> must *not* use the (hierarchical) URI as unique ID, but instead, a different
> non-hierarchical URI which corresponds to the new property DAV:resource-id.
> Moreover, it must implement a "resolve" mechanism which, at store interface,
> transforms hierarchical URIs into unique resource IDs. That is mainly what
> we have done in our Tamino-based store implementation. Details will follow.
> 
> Hope the changes do not cause any inconveniences. At all events, I created a
> CVS tag "SLIDE_2_0_0" before check-in.
> 
> Regards,
> Peter
>