jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Moseley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-249) Webdav: Review usage of command chains
Date Thu, 20 Oct 2005 15:48:48 GMT
    [ http://issues.apache.org/jira/browse/JCR-249?page=comments#action_12332599 ] 

Brian Moseley commented on JCR-249:
-----------------------------------

none of the jcr-server commands need it, but all of my custom commands do.

i use spring to wire together dependencies for all of my custom components. my subclass of
SimpleWebdavServlet makes spring's WebApplicationContext available to my subclass of DavResourceImpl,
which then needs to pass it down to my import and export handlers. the only way i can do this
today is by subclassing ImportContext and ExportContext, and even to achieve that i had to
make a few changes to DavResourceImpl.

in general it is always possible for the resource to have additional information besides the
backing node that the import/export handlers need to do their job correctly. its much easier
to write an import handler that can call resource methods directly than to jump through hoops
with intermediary context classes.

ultimately i'm considering some more extensive surgery to jcr-server so that it doesn't use
the chain stuff at all. i've gotten to the point where my chains are each one command only
:) these commands simply delegate their actual work to a data access object of my own creation,
so the chain executation is really just overhead at this point. i still see the chain's usefulness
to others tho.

i propose that whatever replacement you come up with, you hide it behind an interface so that
it's as easy as possible for people to provide alternate import/export implementations, cos
they will inevitably find a need for that level of flexibility - i already have.


> Webdav: Review usage of command chains
> --------------------------------------
>
>          Key: JCR-249
>          URL: http://issues.apache.org/jira/browse/JCR-249
>      Project: Jackrabbit
>         Type: Improvement
>     Reporter: angela
>     Assignee: angela

>
> i'd like to review the usage of command chains for import/export within the simple webdav
server.
> while the concept of command chains offers a lot of flexibility, it showed that the implementation
generates some drawbacks. a new mechanism should take advantage of the experiences made with
the command chains.
> from my point of view the following issues should be taken into consideration:
> - provide means to extend and modify the import/export logic with minimal effort
> - consistent import/export functionality for both collections and non-collections
>   > export/import should not be completely separated.
>   > interfaces should encourage consistency
>   > increase maintainability, reduce no of errors
> - distinction of collections and non-collections for import/export behaviour
>   > PUT must result in non-coll, MKCOL in collection
> - allow to defined a set of import/export-handlers with a given order.
> - the different handlers must not rely on each other.
> - an import/export should be completed after the first handler indicates success. there

>   should not be other classes involved in order to complete the import/export.
> - avoid huge configuration files and if possible, avoid program flow being defined outside
of java code.
> - avoid duplicate configuration (e.g. resource-filtering), duplicate code, duplicate
logic, that is 
>   hard to maintain.
> - additonal logic should be defined within a given import/export handler.
>   however, in case of webdav i see limited value of using extra logic such as addMixin
or checkin, 
>   that are covered by  webdav methods (such as LOCK, VERSION-CONTROL or CHECKIN).
> regards
> angela

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message