jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Status of jcr-server
Date Tue, 04 Apr 2006 17:07:27 GMT
Angela,

first of all many thanks for you long reply. Comments inline.

Angela Schreiber wrote:
> hi julian
> 
>> First step was to run the generic test suite Litmus 
>> (<http://www.webdav.org/neon/litmus/>), which currently reports a 
>> range of failures, 
> 
> i let litmus run a couple of times in the past and send
> the commented results to the list:
> 
> 1) initial litmus result.
>    that post also explains, why PROPPATCH fails with the
>    default setup: by default non-collection resources represent
>    jcr nodes with nodetype nt:file. This nodetype does not allow
>    to set random properties.
> http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg02792.html 
> 
> 
> 2) a more recent test (after reworking the dav-library while
>    getting rid of JDOM)
> 
> http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg04037.html 

Thanks for the pointer (Yes, I should have scanned the mailing list 
archives first. Sorry.).

One difference over here is that I apparently have a newer Litmus 
version (0.10.5) which includes more test cases (see below). You may 
want to update your copy :-).

Regarding PROPPATCH: understood. However, I really tried hard but 
couldn't figure out so far how to reconfigure the system so that custom 
properties are allowed? Or does this require a change in the code base?

 From the p.o.v. of the user of a generic WebDAV server, I'd expect 
custom properties to be supported.

>> some of which seem to be trivial (non wellformed request bodies not 
>> rejected with status 400), 
> 
> brian originally posted findings resulting from litmus
> tests. at that time we decided, that we try to work around
> invalid xml within PROPFIND although this is not compliant
> with the RFC. if i'm not mistaken, there is still a 'todo' in
> the webdav-request impl class.

Yes, there is. Right now, PROPFIND with a broken request body behaves as 
if no body was present. I think that's a bug, and I don't think any 
client relies on that. From an implementation point of view, the generic 
method that gets the DOM of the request body should have a flag 
(indicating whether a request body is required), and it should be 
allowed to throw an exception (when required body not present, or body 
not wellformed). From a debugging point of view, returning the message 
of the XML parser exception in the response body may be useful for 
developers implementing custom clients...

>> some not (such as If header evaluation problems, 
> 
> this one i missed so far :)

See below.

>> Also, what are the current goals for jcr-server? Is it just a 
>> proof-of-concept, or is it supposed to become a fully compliant 
>> implementation of the applicable RFCs? Is it supposed to follow the 
>> changes in RFC2518bis as well?
> 
> at the very beginning the aim was to provide a 'simple'
> dav-view to a JSR170 compliant repository (that what we
> still call the 'simple server') as well as a webdav
> remoting for a JSR170 repository (the 'jcr-server').

Ah. I was completely confused by the the two different things, now I 
understand :-).

> the webdav library which does not have any dependencies
> to the jcr-api was just a side-effect of the efforts
> made for the server implementations... in the meantime
> we put some work into the library, to improve compliance
> with the various webdav RFCs.
> 
> regarding compliance of the 2 implementations:
> 
> a) jcr-server: since the aim of this impl is to provide
>    remoting of the jsr170 api; compliance to dav-RFC is
>    fine but not the primary goal.
> 
> b) simple-server: compliance it definitely required.
>    however, the supported feature-set is forced by the
>    underlying repository. its not the dav-implementation that
>    builts or govers the data storage. i guess, this has been
>    the source of some misunderstanding in the past.
>    currently the simple-server only implements compliance
>    levels 1,2. jeremi planned to add additional functionality
>    to the simple server.

I think it would be interesting to come up with a plan that would avoid 
that distinction. A "common" server like that would be a fully compliant 
(or as compliant as possible) server, and the JCR functionality that 
doesn't map properly would be hidden somehow from generic clients. That way.

> for further information regarding aims and current status
> of the jcr-server see the following posts:
> 
> http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03658.html 
> 
> http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03693.html 
> 
> http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03762.html 

Thanks.

Below are the Litmus 0.10.5 results I'm currently seeing, with in-lined 
comments.


-> running `basic':
  0. init.................. pass
  1. begin................. pass
  2. options............... pass
  3. put_get............... pass
  4. put_get_utf8_segment.. pass
  5. mkcol_over_plain...... pass
  6. delete................ pass
  7. delete_null........... pass
  8. delete_fragment....... pass
  9. mkcol................. pass
10. mkcol_again........... pass
11. delete_coll........... pass
12. mkcol_no_parent....... pass
13. mkcol_with_body....... pass
14. finish................ pass
<- summary for `basic': of 15 tests run: 15 passed, 0 failed. 100.0%
-> running `copymove':
  0. init.................. pass
  1. begin................. pass
  2. copy_init............. pass
  3. copy_simple........... pass
  4. copy_overwrite........ pass
  5. copy_nodestcoll....... WARNING: COPY to non-existant collection 
'/jackrabbit-server/repository/default/litmus/nonesuch' gave '403 
Forbidden' not 409
     ...................... pass (with 1 warning)

In 
<http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg02792.html>, 
you wrote:

"[ note: because 'shallow' copy is not possible with jcr and results in 
503.
         test would pass otherwise ]"

I'm not sure what the reference about shallow copy is about; as far as I 
can tell, Litmus is doing a deep (default) copy, and just wants the 
server to reject the request with 409 because that's what RFC2518 
mandates when the parent collection for the target resource doesn't exist.

  6. copy_cleanup.......... pass
  7. copy_coll............. pass
  8. move.................. pass
  9. move_coll............. pass
10. move_cleanup.......... pass
11. finish................ pass
<- summary for `copymove': of 12 tests run: 12 passed, 0 failed. 100.0%
-> 1 warning was issued.
-> running `props':
  0. init.................. pass
  1. begin................. pass
  2. propfind_invalid...... FAIL (PROPFIND with non-well-formed XML 
request body got 207 response not 400)
  3. propfind_invalid2..... FAIL (PROPFIND with invalid namespace 
declaration in body (see FAQ) got 207 response not 400)

(see above)

  4. propfind_d0........... pass
  5. propinit.............. pass
  6. propset............... FAIL (PROPPATCH on 
`/jackrabbit-server/repository/default/litmus/prop': 
http://localhost:8080/jackrabbit-server/repository/default/litmus/prop: 
409 Conflict )
  7. propget............... SKIPPED
  8. propextended.......... pass
  9. propmove.............. SKIPPED
10. propget............... SKIPPED
11. propdeletes........... SKIPPED
12. propget............... SKIPPED
13. propreplace........... SKIPPED
14. propget............... SKIPPED
15. propnullns............ SKIPPED
16. propget............... SKIPPED
17. prophighunicode....... SKIPPED
18. propget............... SKIPPED
19. propvalnspace......... SKIPPED
20. propwformed........... pass
21. propinit.............. pass
22. propmanyns............ FAIL (PROPPATCH on 
`/jackrabbit-server/repository/default/litmus/prop': 
http://localhost:8080/jackrabbit-server/repository/default/litmus/prop: 
409 Conflict )
23. propget............... FAIL (No value given for property 
{kappa}somename)
24. propcleanup........... pass
25. finish................ pass
-> 12 tests were skipped.
<- summary for `props': of 14 tests run: 9 passed, 5 failed. 64.3%
-> running `locks':
  0. init.................. pass
  1. begin................. pass
  2. options............... pass
  3. precond............... pass
  4. init_locks............ pass
  5. put................... pass
  6. lock_excl............. pass
  7. discover.............. pass
  8. refresh............... pass
  9. notowner_modify....... WARNING: PROPPATCH failed with 0 not 423
     ...................... pass (with 1 warning)
10. notowner_lock......... pass
11. owner_modify.......... pass
12. notowner_modify....... WARNING: PROPPATCH failed with 0 not 423
     ...................... pass (with 1 warning)

As mentioned in your earlier email, this is because Litmus expects a 423 
instead of a 207 with embedded 423 status. I would say that Litmus is 
correct to expect that, as multistatus shouldn't be used unless it's 
required by the method definition (in this case, it doesn't seem to make 
sense as only one resource would have been affected, and the error is 
actually reported for the resource at the request-URI).

I think the majority of other implementations doesn't return a 207 here, 
so I wouldn't really be surprised if a client would be confused by that.

13. notowner_lock......... pass
14. copy.................. FAIL (could not COPY locked resource:
403 Forbidden)

(not sure about this one)

15. cond_put.............. pass
16. fail_cond_put......... pass
17. cond_put_with_not..... pass
18. cond_put_corrupt_token WARNING: PUT failed with 412 not 423
     ...................... pass (with 1 warning)

In this case, an If header specifies two no-tag-lists productions, of 
which one always evaluates to true; thus checking the If header should 
not fail, and execution of the method should proceed. A 423 is expected 
because the required lock token indeed wasn't submitted in the If header.


19. complex_cond_put...... pass
20. fail_complex_cond_put. pass
21. unlock................ pass
22. fail_cond_put_unlocked FAIL (conditional PUT with invalid lock-token 
should fail: 204 No Content)

Here, the tests *did* expect a 412, because the If header contained a 
single No-tag-list, wich evaluates to false. In general, just because a 
resource isn't locked doesn't mean the If header doesn't need to be 
evaluated.

23. lock_shared........... FAIL (LOCK on 
`/jackrabbit-server/repository/default/litmus/lockme': 412 Precondition 
Failed)

This is expected to fail if no shared locks are supported; however 412 
seems to be fishy here, as no conditional header is present in the request.

24. notowner_modify....... SKIPPED
25. notowner_lock......... SKIPPED
26. owner_modify.......... SKIPPED
27. double_sharedlock..... SKIPPED
28. notowner_modify....... SKIPPED
29. notowner_lock......... SKIPPED
30. unlock................ SKIPPED
31. prep_collection....... pass
32. lock_collection....... pass
33. owner_modify.......... pass
34. notowner_modify....... WARNING: PROPPATCH failed with 0 not 423
     ...................... pass (with 1 warning)
35. refresh............... pass
36. indirect_refresh...... pass
37. unlock................ pass
38. finish................ pass
-> 7 tests were skipped.
<- summary for `locks': of 32 tests run: 29 passed, 3 failed. 90.6%
-> 4 warnings were issued.
-> running `http':
  0. init.................. pass
  1. begin................. pass
  2. expect100............. pass
  3. finish................ pass
<- summary for `http': of 4 tests run: 4 passed, 0 failed. 100.0%





Best regards, Julian


Mime
View raw message