jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: [jira] Commented: (JCR-165) add ability to ignore specific node types when generating webdav directory listing
Date Fri, 15 Jul 2005 16:06:25 GMT
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.

Mime
View raw message