Tobias Strasser wrote:
what i like of the chain approach is the easy configurability. but it needs a very good understanding what the respective commands do, and they have to work properly together. maybe we have to define some proper constraints and invariants for the commands; without having access to the sourcecode or a very good documentation, you will probably not be able to configure proper chains.
can you imagine a situation in which one would want to configure an import or export chain without being able to look at the sourc code?
i think tweaking the default import/export behavior is an advanced activity that relatively few people will want to do, and those who try will almost certainly be developers who will understand how to read source code and developer-level docs.
i do think that documenting how the chains work and what the default commands and configuration do would be valuable, but i was able to figure it out with a relatively quick inspection of the source code, so i don't see it as a pressing concern.
i also stumbled over a (what i think is) design flaw of the chains, that they 'store' the catalog in class-static fields. this makes it for example in a j2ee impossible to hold different catalogs (with the same name) in the same webapp (or worse, in the entire server, if you place the commons-chain.jar in the wrong place). correct me if i'm wrong here. as next step, i would also try to use the catalogs more strictly, and not via class-loader magic.
in a j2ee context you could store the catalog in jndi or in a servlet context attribute. you could load the catalog during servlet initialization or with a servlet context listener.
you could also write container-specific components to make the chain available as a jndi resource, although that seems like overkill in a couple of different ways.
the idea here was, that the export/import chains could also be used in a non-j2ee environment, where request/response are not available.
sure, but when you are guaranteed to be in a j2ee environment, such as when a servlet sets up the chains, it could provide them with servlet-aware contexts.
perhaps you could retain the existing import and export context classes, and then create j2ee-aware subclasses with access to the request, response, and servlet, and have the webdav servlet give those to the chains.
this would give me the flexibility i need for generating a custom directory listing but also make the chains available for use in non-j2ee environments.
if you like this approach, i can send you a patch. it's basically the strategy i was going to follow on my own anyway :)
we can do that. no problem.
great. i think that's the appropriate design approach for pretty much all of the jcr-server classes. i find that implementing my webdav protocol extensions calls for overriding the jcr-server classes in many different places, and right now i'm maintaining an extensive set of small patches that add accessor methods to jcr-server classes and/or make private methods protected or public.
