jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Strasser <tobias.stras...@gmail.com>
Subject Re: webdav configuration api
Date Sat, 09 Apr 2005 10:46:24 GMT
ok. i gave it a try. the actual chaining really adds value to the
code. that is cool.
i also figured out how the commands can be parametrized. the digester
calls the respective bean methods, for each attribute in the xml.

cheers, tobi

On Apr 8, 2005 6:55 PM, Brian Moseley <bcm@osafoundation.org> wrote:
> Tobias Strasser wrote:
> > and how do you pass parameters to the commands?
> > or would you create a 'MakeVersionable' command?
> good question. that probably takes us back to the original discussion,
> which was about configuration. but if we assume we have some object that
> contains config info, then we make it part of the chain's command context.
> really, these two issues are orthogonal: 1) general configuration of
> server components and 2) more sophisticated resource import and export.
> an extensible import/export design would benefit from a declarative
> configuration, but this is not the same thing as setting behavioral
> parameters for the server in general.
> we've identified a couple cases where we need general server config.
> presumably we will also need a general way to configure individual
> import/export handlers.
> i'm still in favor of a simple config object loaded by the servlet that
> can be passed around between components. maybe commons config? :)
> > well, just another 2 libraries we depend on...
> > but i'll give it a try and maybe i discover the beauty of commons-chain :-)
> two libraries? oh, are you talking about digester?
> it may be that a commons chain implementation *is* overkill, but i don't
> think i could make that conclusion without giving it a try. but it sure
> seems to fit the need here.
> why do you worry about library dependencies? are you concerned about
> bloating the distribution's file size? when there is a clear benefit,
> and the alternative is writing code that has to be maintained by *this*
> project, using external libraries is often a good choice, even if it
> makes the download time a little longer. it's not like this is a client
> app that will be downloaded by tens of millions :)

------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

View raw message