You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2005/10/11 12:45:37 UTC
[jira] Created: (JCR-249) Webdav: Review usage of command chains
Webdav: Review usage of command chains
--------------------------------------
Key: JCR-249
URL: http://issues.apache.org/jira/browse/JCR-249
Project: Jackrabbit
Type: Improvement
Reporter: angela
Assigned to: 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
[jira] Commented: (JCR-249) Webdav: Review usage of command chains
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-249?page=comments#action_12332582 ]
angela commented on JCR-249:
----------------------------
hi brian
could you explain what is the use-case for having access to the resource in the import/export?
the only command - as far as i know - that would currently need this information is the 'dirlisting' which does not really belong to the import/export... what it should do (and currently doesn't) is providing a list that corresponds to a PROPFIND with depth=1... but this is not a export that is driven by the repository items but rather by the dav-resource or itself, which knows about its members.
kind regards
angela
> 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
[jira] Closed: (JCR-249) Webdav: Review usage of command chains
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-249?page=all ]
angela closed JCR-249:
----------------------
> 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
[jira] Commented: (JCR-249) Webdav: Review usage of command chains
Posted by "Brian Moseley (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (JCR-249) Webdav: Review usage of command chains
Posted by "Brian Moseley (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-249?page=comments#action_12331804 ]
Brian Moseley commented on JCR-249:
-----------------------------------
the import/export handlers should also have access to the resource that is being imported or exported itself, not just the backing node. this gives greater flexibility for DavResource implementations to provide additional collaborating objects to the handlers.
> 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
[jira] Resolved: (JCR-249) Webdav: Review usage of command chains
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-249?page=all ]
angela resolved JCR-249:
------------------------
Resolution: Fixed
issues has been solved.
i will add a description of the changes as soon as changes are available.
> 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
[jira] Commented: (JCR-249) Webdav: Review usage of command chains
Posted by "angela (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-249?page=comments#action_12356964 ]
angela commented on JCR-249:
----------------------------
overview over changes implied by the removal of the command-chains:
Chain, Command and Context replacement
--------------------------------------------------------------------------------------------------------------
chain -----> IOManager interface
command -----> IOHandler interface
context -----> IOContext base interface
-----> ImportContext interface
-----> ExportContext interface
IOHandler covers the corresponding import AND export
for both collections and non-collections.
nevertheless, it is possible that a given implementation
only handles export or import (then the corresponding
'canImport/canExport' must return false).
IOManager is used to define a list of IOHandlers
that can be asked for a specific import/export. note.
in contrast to the command-chains the import/export
should be considered completed as soon as the first
handler indicates success.
both the IOManager and the IOHandler allow to run
the import/export either with a DavResource or with a boolean
flag indication if a collection is affected.
I extracted slightly modified interfaces from the original context
classes. Apart from the common methods (covered by IOContext), the
ImportContext interface allows to get related properties, the ExportContext
however only allows to set them.
After the import/export is completed (success or failure)
the context must be 'released' by calling 'informCompleted'.
Utilities
--------------------------------------------------------------------------------------------------------------
Common utitily methods present in the abstract commands
and in the NodeResource class were moved to a IOUtil.java.
Configuration
--------------------------------------------------------------------------------------------------------------
catalog.xml is not used any more.
The resource configuration should define an IOManager.
If the configuration entry is missing the default impl. is used as fallback.
Commands in detail
--------------------------------------------------------------------------------------------------------------
AddNode
FileImport
FileExport -------> DefaultIOHandler
ZipImport -------> ZipHandler
[ new: covers also export ]
XmlImport
XmlExport -------> XmlHandler
[ only generic xml, see below ]
DirListing -------> DirListingExportHandler
[ note: no import ]
SetContentType
SaveCommand
Checkin
AddMixin -------> no replacement
PrimaryItem -------> was not used. no replacement inside jackrabbit.
NOTE regarding xml import/export. The import-command
tried to distinguish generic xml from exported sysview/docview
xml files, that were extracted without a file/folder
node being created. This lead to consistency problems.
The new xml-Handler does not make this distinction. if
an xml should be directly extracted below the import-root
a separated handler should take care of this (and should
rather not be used in a webdav context).
regards
angela
> 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