Suggestion for split of JCR-Server

[Angela Schreiber <an...@day.com>]

hi

as mentioned and discussed several times before, we may
think about splitting the 'jcr-server' project into
a webdav specific project and the jcr-server.


1) Proposal for webdav project structure
----------------------------------------------------------------

+ jackrabbit
   + webdav
     + commons
         [ would contain the current webdav library including ]
         [ its dependency to servlet api (see 2)              ]
         [ no dependency to jsr170 api nor jackrabbit         ]
     + server
       + config (see 5)
       + io
       + "simple-server-implementation"
       + "core-server-implementation" (see 4)
     + client
         [ the dav extension of httpclient methods            ]
         [ further dav-client development                     ]
     + webapp
         [ repository-access-servlet, dav-servlets            ]
         [ only here: dependency to jackrabbit                ]


2) Missing separation of commons and server api
-----------------------------------------------------------------

i tried to move everything with dependency to the servlet api
and all the 'resource' interfaces to the 'server' and reduce
the 'commons' to classes/interfaces which are shared between
server and client.

however i found, that both 'DavResource' and the
'DavServletRequest'/'DavServletResponse' are tied too much
into common utilities such as DavMethod and MultiStatus etc.

thus, moving those server specific interfaces out of the
common library would lead to substancial redesign which
i would prefer not to mix with that initial split. instead
this should go into the todos for a major release.


3) Dependencies from 'jcr' package
-----------------------------------------------------------------

the 'simple' currently contains the following dependencies
to the 'jcr' implementation:

- JcrDavException:
   Extension to DavException that translates the various
   RepositoryExceptions to error-codes.

- JcrDavSession:
   Abstract class that wraps javax.jcr.Session and provides
   access to this repository session.

- JcrActiveLock:
   Wraps a javax.jcr.Lock object. This class has a dependency
   to the ItemResourceConstants (destinction of session scoped
   locks) which is useful for the jcr-server only, not for
   'simple' or some generic server.

- The simple servlet uses the locator factory implementation
   from the webdav.jcr package.

I think that all of the mentioned classes in fact represent
a common basis for dav implementations on top of jsr170
compliant repository and should rather be part of a util
package (or of the core?). currently the dependencies are
internal only and a replacement should be possible.


4) What represents the 'core' implementation
------------------------------------------------------------------

i would suggest to use the 'core' as base implementation for
dav-server on top of a jsr170 compliant repository. the
extensions provided by jérémi would then act as basis
for the core. the 'simple' may extend from the 'core' as well
but not the other way round.


5) Why a separate 'server/config'
------------------------------------------------------------------

currently only the 'simple' server provides a simple and limited
configuration. in order to be able to create a configuration
suited for a broader usage and for a general server i would
suggest to start with a separat config package.
the 'simple' package would contain the original config classes
for backwards compatibility (but marked deprecated).


6) what will be in the 'jcr-server'
------------------------------------------------------------------

in the 'jcr-server' would remain the 'webdav/jcr' package,
the 'server/jcr' package and the JCRWebdavServerServlet.java.


what do you think?

regards
angela

Re: Suggestion for split of JCR-Server

[Julian Reschke <ju...@gmx.de>]

Angela,

I can't comment on the specifics (yet), as I'm still new to this 
projects. As far as I can tell, the reorg makes a lot of sense.

I still have the nagging feeling that it may be possible to combine both 
kinds of servers into a single one, thus completely avoiding the 
distinction between to differing HTTP mappings of the store, though. But 
it certainly makes sense to keep this issue distinct from the general 
cleanup.

Best regards (and hopes this makes sense :-)

Julian

Re: Suggestion for split of JCR-Server

[Brian Moseley <bc...@osafoundation.org>]

On 4/19/06, Angela Schreiber <an...@day.com> wrote:

> what do you think?

looks good to me.