Slide 2.1 Testsuite results ...

[Pe...@softwareag.com]

Hi all,

I have been running the testsuite with Slide 2.1 and the Tamino store and I have obtained good results. The testareas DeltaV and BIND are error-free. In DASL 11 testcases fail (OK ... :( ... something I'll have to check in the Tamino store). 

In "functional" I get 2 failing testcases (which is close to error-free!!), which I would like to comment on:

1) functional\copy\mix\copyChangedProperties.xml

   a) I think the testcase shouldn't expect the DAV:displayname property to be set in the *copy* (i.e. the resource created by the COPY step), because setting the displayname automatically - to be the last URI segment - is disabled when binding is enabled. So I propose to change the testcase.

   b) Apparently the testcase reveals a bug, namely that the DAV:owner property of the *copy* isn't set correctly to be the principal issuing the COPY request. Of course, if a resource existed at the destination location and is overwritten by the COPY operation, the owner should not change, as an existing resource is just being updated.
I propose to fix this with 4 lines of code in CopyMethod.afterCopy() ... see attached diff. Or should this go somewhere else? I noticed there is a MacroPropertyUpdater now ... but it is only called if events are enabled, right?

2) functional\move\moveChangedProperties.xml

   Same as 1a): testcase shouldn't assume DAV:displayname being set automatically. As this testcase has no other function I propose to drop it.

Suggestions, comments? Should we fix 1b in 2.1?

Thanks,

Peter

Re: Slide 2.1 Testsuite results ...

[Stefan Lützkendorf <lu...@apache.org>]

Hi Peter,
I know the problem with this test cases. I've added them to verify the
the properties updater.
It is very dependend on the configuration of the server and not a DAV
requirement. So I think we can drop them (or find a special place for
such stuff).

The MacroPropertyUpdater was mainly intended to give a configurable way
of using the displayname property as "filename" as required by some
clients. So I would agree to move the owner update/creator update
to the MarcoImpl etc. and fix it for 2.1.

Regards Stefan


Peter.Nevermann@softwareag.com wrote:

> Hi all,
> 
> I have been running the testsuite with Slide 2.1 and the Tamino store and I have obtained good results. The testareas DeltaV and BIND are error-free. In DASL 11 testcases fail (OK ... :( ... something I'll have to check in the Tamino store). 
> 
> In "functional" I get 2 failing testcases (which is close to error-free!!), which I would like to comment on:
> 
> 1) functional\copy\mix\copyChangedProperties.xml
> 
>    a) I think the testcase shouldn't expect the DAV:displayname property to be set in the *copy* (i.e. the resource created by the COPY step), because setting the displayname automatically - to be the last URI segment - is disabled when binding is enabled. So I propose to change the testcase.
> 
>    b) Apparently the testcase reveals a bug, namely that the DAV:owner property of the *copy* isn't set correctly to be the principal issuing the COPY request. Of course, if a resource existed at the destination location and is overwritten by the COPY operation, the owner should not change, as an existing resource is just being updated.
> I propose to fix this with 4 lines of code in CopyMethod.afterCopy() ... see attached diff. Or should this go somewhere else? I noticed there is a MacroPropertyUpdater now ... but it is only called if events are enabled, right?
> 
> 2) functional\move\moveChangedProperties.xml
> 
>    Same as 1a): testcase shouldn't assume DAV:displayname being set automatically. As this testcase has no other function I propose to drop it.
> 
> Suggestions, comments? Should we fix 1b in 2.1?
> 
> Thanks,
> 
> Peter

-- 
Stefan Lützkendorf  -- luetzkendorf@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org