> > perhaps a compelling reason not to use the command-chains in > > that particular case? ;) > > what's the alternative - major surgery on DavResourceImpl? > > nah, i like the chain approach. hey i suggested it, right? :) 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. 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.
> if y'all are really dead set on not having contexts that > include the request and the response (i'm not sure why you > would be), the idea here was, that the export/import chains could also be used in a non-j2ee environment, where request/response are not available. > then maybe you can move the instantiation of each > chain into a protected method that a subclass can override? we can do that. no problem. cheers, tobi -- ------------------------------------------< [EMAIL PROTECTED] >--- 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 >---
