You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2006/04/04 14:51:50 UTC
Status of jcr-server
Hi.
I just spent some time starting to get familiar with JCR in general, and
with Jackrabbit and jcr-server in particular. Now that everything is up
and running (built from svn, running in Tomcat 5.0.x, just with all the
default settings), I've started to look into the actual WebDAV server
implementation.
First step was to run the generic test suite Litmus
(<http://www.webdav.org/neon/litmus/>), which currently reports a range
of failures, some of which seem to be trivial (non wellformed request
bodies not rejected with status 400), some not (such as If header
evaluation problems, PROPPATCH tests all failing).
In the mid-term, I'd like to contribute to jcr-server, both in fixing
compliance problems, but also in adding features (Redirect support?
Property datatype support). For now, what's the best way to start? If
I'm sure I found an actual problem in the code, should I open a bug
report over at <http://issues.apache.org/jira/browse/JCR>, then try to
provide a patch?
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?
Best regards,
Julian
Re: Status of jcr-server
Posted by Brian Moseley <bc...@osafoundation.org>.
On 4/4/06, Julian Reschke <ju...@gmx.de> wrote:
> As far as I can tell this means that neither "jcr-server" (the thingy in
> the "server" subdirectory) nor "simple-server" (the one on the "webapp"
> subdirectory) will act as generic WebDAV servers: one exposes too much,
> the other one too little of the capabilities of JCR.
pretty much.
> So is a generic WebDAV server setup that could act as a drop-in
> replacement for things such as Apache/mod_dav, IIS or Slide in scope of
> this Apache activity, or would I need to start my own project for that?
> (Understanding that Cosmo may be part of the answer :-)
there was a thread a couple months ago about doing just this. a few of
the folks from the slide community were interested then, but i have no
idea what's going on over there these days.
there's quite a bit of dav code in cosmo that could probably be
donated to the asf (need to doublecheck first). i've been busy with
other stuff at osaf, but now i can make time to address this, starting
tomorrow very possibly.
i think the easiest, most efficient way to get the ball rolling would
be to create another contrib project. that way we don't pollute
jcr-server in case the effort dies out, and we avoid the politics of
coming out of the gate aiming for some kind of top level thinger.
i'm a bit distracted right now, so i may have overlooked something
important. call me out if i have :)
Re: Status of jcr-server
Posted by Julian Reschke <ju...@gmx.de>.
Brian Moseley wrote:
>> I'm still confused. Is this a limitation of the "simple" server, or one
>> of the backends?
>
> sorry. when i said "back end", i was referring to the "simple server"
> and "jcr remoting server" implementations of the jcr-server
> interfaces. the implementation of simple server exists in order to
> offer webdav protocol access to a repository full of nt:folder and
> nt:file nodes. it does not offer any other options.
OK, thanks for the clarification.
As far as I can tell this means that neither "jcr-server" (the thingy in
the "server" subdirectory) nor "simple-server" (the one on the "webapp"
subdirectory) will act as generic WebDAV servers: one exposes too much,
the other one too little of the capabilities of JCR.
So is a generic WebDAV server setup that could act as a drop-in
replacement for things such as Apache/mod_dav, IIS or Slide in scope of
this Apache activity, or would I need to start my own project for that?
(Understanding that Cosmo may be part of the answer :-)
Best regards, Julian
Re: Status of jcr-server
Posted by Brian Moseley <bc...@osafoundation.org>.
On 4/4/06, Julian Reschke <ju...@gmx.de> wrote:
> Brian, thanks for the additional information. I do understand that
> there'll be backends that do not offer all the features, and yes, I
> think it's absolutely fine to expose these kinds of resources through
> WebDAV (witness all the history of discussions on the WebDAV mailing
> list :-).
>
> As a newbie to this code, I was trying to understand what I need to do
> to configure a system that *does* support custom properties (otherwise
> it's pretty pointless to run compliance test suites).
there's no simple configuration change you can make. you'd have to:
1) define new node types that allow custom properties
2) provide an alternate implementation of DavResource (and perhaps a
few other interfaces) and at least one new io handler that store nodes
of your newly defined types
> I'm still confused. Is this a limitation of the "simple" server, or one
> of the backends?
sorry. when i said "back end", i was referring to the "simple server"
and "jcr remoting server" implementations of the jcr-server
interfaces. the implementation of simple server exists in order to
offer webdav protocol access to a repository full of nt:folder and
nt:file nodes. it does not offer any other options.
Re: Status of jcr-server
Posted by Julian Reschke <ju...@gmx.de>.
Brian Moseley wrote:
> On 4/4/06, Julian Reschke <ju...@gmx.de> wrote:
>
>> 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?
>
> this is what angela meant when she said the repository implementation
> drives the simple server's feature set, not the other way around.
>
> because data is persisted by the simple server as nt:folder and
> nt:file nodes, there's no way to store custom properties on a webdav
> resource or collection.
>
> in constrast, for cosmo i have defined dav:collection and dav:resource
> node types that extend nt:folder and nt:file, adding a dav:displayname
> property as well as custom properties.
Brian, thanks for the additional information. I do understand that
there'll be backends that do not offer all the features, and yes, I
think it's absolutely fine to expose these kinds of resources through
WebDAV (witness all the history of discussions on the WebDAV mailing
list :-).
As a newbie to this code, I was trying to understand what I need to do
to configure a system that *does* support custom properties (otherwise
it's pretty pointless to run compliance test suites).
> thus the discussion (which none of us have acted on yet) about
> providing a third "back end" for jcr-server that does not limit itself
> to node types defined by the jcr spec and which therefore can more
> fully implement webdav and its many extensions.
I'm still confused. Is this a limitation of the "simple" server, or one
of the backends?
>> 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...
>
> fwiw, i've patched the version of jackrabbit used by cosmo to do
> exactly these things. i have not yet had time to migrate that to the
> main jackrabbit repository.
Thanks for confirming. I guess I'll first submit a bug to Jira, and then
we can think about who's going to fix it.
Best regards, Julian
Re: Status of jcr-server
Posted by Brian Moseley <bc...@osafoundation.org>.
On 4/4/06, Julian Reschke <ju...@gmx.de> wrote:
> 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?
this is what angela meant when she said the repository implementation
drives the simple server's feature set, not the other way around.
because data is persisted by the simple server as nt:folder and
nt:file nodes, there's no way to store custom properties on a webdav
resource or collection.
in constrast, for cosmo i have defined dav:collection and dav:resource
node types that extend nt:folder and nt:file, adding a dav:displayname
property as well as custom properties.
thus the discussion (which none of us have acted on yet) about
providing a third "back end" for jcr-server that does not limit itself
to node types defined by the jcr spec and which therefore can more
fully implement webdav and its many extensions.
> 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...
fwiw, i've patched the version of jackrabbit used by cosmo to do
exactly these things. i have not yet had time to migrate that to the
main jackrabbit repository.
Re: Status of jcr-server
Posted by Brian Moseley <bc...@osafoundation.org>.
On 4/5/06, Angela Schreiber <an...@day.com> wrote:
> - its a configuration issue that nt:file serves as non-collection
> by default. for a simple dav-view on top of the jsr170
> reference implementation this definitely makes sense.
>
> - how a MKCOL and a PUT is translated to the calls on the
> JCR170 repository is a matter of the IOManager used for
> import/export. the IOManager again can be configured.
my point is that julian does not get everything he needs out of the
box to support custom properties with only configuration changes. he
needs to
1) define and register new node types that allow custom properties
2) provide new IOManager/IOHandler/whatever that set and read the
custom properties
3) tweak a config file to make jcr-server use his new io classes
rather than the defaults
> - basically for level 1,2 compliance you would not have to create
> your own DavResource implementation. additional RFC have not
> be implemented for the simple stuff as noone claimed for it
> (see mail conversation with jeremi).
ok, fair enough, you aren't required to. i'd suggest it, however. for
a while i've been feeling the pain of a single DavResource
implementation representing both collections and non-collection
resources, and the pain gets more intense when you start accounting
for new resource types like calendar collections.
Re: Status of jcr-server
Posted by Angela Schreiber <an...@day.com>.
hi julian
Julian Reschke wrote:
> From the p.o.v. of the user of a generic WebDAV server, I'd expect
> custom properties to be supported.
sure. but the aim of the dav implementations in
jackrabbit is to provide a thin dav-layer to the
reference implementation of the jsr170 repository.
from my understanding webdav is a protocol and
therefore just one way to look at any kind content
that is accessible by a 'repository' which provides
some sort of api.
even more, there could be various ways to take a
webdav-look at the same repository (be it jsr170 compliant
or something totally different) revealing different
aspects or different levels of granularity.
saying this explains, why there is a dav-library
that tries to abstract the functionality required
by the protocol and offers interfaces to implement
a thin dav-view on top of a repository (again using
'repository' in a general sense not focus on JSR170).
and finally this was one of reason not to follow the
initial attempt to use slide, which from my understanding
makes the protocol reign the repository.
Brian wrote:
> because data is persisted by the simple server as nt:folder and
> nt:file nodes, there's no way to store custom properties on a webdav
> resource or collection.
this is not totally correct:
- its a configuration issue that nt:file serves as non-collection
by default. for a simple dav-view on top of the jsr170
reference implementation this definitely makes sense.
- how a MKCOL and a PUT is translated to the calls on the
JCR170 repository is a matter of the IOManager used for
import/export. the IOManager again can be configured.
- basically for level 1,2 compliance you would not have to create
your own DavResource implementation. additional RFC have not
be implemented for the simple stuff as noone claimed for it
(see mail conversation with jeremi).
Julian Reschke wrote:
> I think it would be interesting to come up with a plan that would avoid
> that distinction.
no. the 2 implementations are distinct.
if you are looking for some sort of webdav-support, forget
about the remoting part (what we called 'jcr-server').
this is not as gary possibly thinks the attempt to do
jsr170 - <network> - webdav
instead the aim is to do
jsr170 - network - jsr170
it would be equally possible to use http1.1 without
webdav extensions and remote the jsr170 calls by GET
and PUT having any kind of proprietary request body
format. again: webdav is the protocol only.
> 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.
yes one could built such a 'server'. but then you have
to make sure your underlaying JSR170 repository supports
the nodetypes you are defining in order to support
e.g. full PROPPATCH support. and you are forcing the
repository to be version-enabled if you define your
generic-dav-server to be compliant to DeltaV.
even further: JSR170 does not define how access control
is modeled. having a dav-server supporting RFC 3744 you
will end up defining how the repository behaves.
regards
angela
ps: i'll take a look at your litmus findings. thanks for
pointing this out.
Re: Status of jcr-server
Posted by Julian Reschke <ju...@gmx.de>.
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
Re: Status of jcr-server
Posted by jeremi joslin <je...@gmail.com>.
On 4/4/06, Angela Schreiber <an...@day.com> wrote:
[snip]
> 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.
Hi,
Yes, I'm working on the DeltaV functionality. I have some problems, i
will post about it soon, specially with non deltaV aware clients.
Jérémi
--
Blog: http://www.jeremi.info
LinkedIn: https://www.linkedin.com/profile?viewProfile=&key=1437724
Project Manager XWiki: http://www.xwiki.org
skype: jeremi23 -- msn et gtalk : jeremi23@gmail.com
Re: Status of jcr-server
Posted by Angela Schreiber <an...@day.com>.
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
> 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.
> some not (such as If header evaluation problems,
this one i missed so far :)
> PROPPATCH tests all failing).
see 1)
> In the mid-term, I'd like to contribute to jcr-server, both in fixing
> compliance problems, but also in adding features (Redirect support?
> Property datatype support).
sounds good. there is couple of other things missing in the
library, where you could contribute.
> For now, what's the best way to start?
since there is almost no documentation except for things
discussed within this mailing list, you may start looking
at the code.
> If I'm sure I found an actual problem in the code, should I open a bug
> report over at <http://issues.apache.org/jira/browse/JCR>, then try to
> provide a patch?
yes please.
> 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').
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.
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
kind regards
angela
Re: Status of jcr-server
Posted by Gary Gershon <ge...@celsus.net>.
Hi Julian,
Just wanted to chime in that I'm also interested in contributing as best I
can to the JCR WebDAV effort, particularly in regard to the use of WebDAV
with the backend SPI. That is, using the JCR API as a client for remotely
accessing (existing) WebDAV server implementations.
Regards,
Gary
On 4/4/06 7:51 AM, "Julian Reschke" <ju...@gmx.de> wrote:
> Hi.
>
> I just spent some time starting to get familiar with JCR in general, and
> with Jackrabbit and jcr-server in particular. Now that everything is up
> and running (built from svn, running in Tomcat 5.0.x, just with all the
> default settings), I've started to look into the actual WebDAV server
> implementation.
>
> First step was to run the generic test suite Litmus
> (<http://www.webdav.org/neon/litmus/>), which currently reports a range
> of failures, some of which seem to be trivial (non wellformed request
> bodies not rejected with status 400), some not (such as If header
> evaluation problems, PROPPATCH tests all failing).
>
> In the mid-term, I'd like to contribute to jcr-server, both in fixing
> compliance problems, but also in adding features (Redirect support?
> Property datatype support). For now, what's the best way to start? If
> I'm sure I found an actual problem in the code, should I open a bug
> report over at <http://issues.apache.org/jira/browse/JCR>, then try to
> provide a patch?
>
> 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?
>
> Best regards,
>
> Julian
>