Return-Path: Delivered-To: apmail-jakarta-log4j-dev-archive@apache.org Received: (qmail 34164 invoked from network); 15 May 2002 19:35:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 May 2002 19:35:00 -0000 Received: (qmail 1467 invoked by uid 97); 15 May 2002 19:35:01 -0000 Delivered-To: qmlist-jakarta-archive-log4j-dev@jakarta.apache.org Received: (qmail 1401 invoked by uid 97); 15 May 2002 19:35:00 -0000 Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@jakarta.apache.org Received: (qmail 1382 invoked by uid 98); 15 May 2002 19:35:00 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Wed, 15 May 2002 20:35:40 +0100 Subject: Re: ideas for dynamic configuration Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: robert burrell donkin To: "Log4J Developers List" Content-Transfer-Encoding: quoted-printable In-Reply-To: <5.1.0.14.0.20020515105453.00b99740@mail.qos.ch> Message-Id: X-Mailer: Apple Mail (2.481) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wednesday, May 15, 2002, at 11:32 AM, Ceki G=FClc=FC wrote: > At 22:04 14.05.2002 +0100, you wrote: >> the first strategy is to allow the subcomponents to configure = themselves=20 >> using bean-like rules. the idea is that the object to be configured = must=20 >> conform to certain patterns similar to getters and setters for the=20 >> xml->object mapping. (xo and betwixt in the commons-sandbox were = created=20 >> with this philosophy in mind.) >> >> this strategy has the advantage of being more secure and offers less=20= >> room for configuration conflicts. it's also much easier to explain to = an=20 >> implementor that these are the rules that their beans need to follow = to=20 >> make the configuration work properly than it is to say - go learn=20 >> digester. > > Interesting approach. Do you have an idea of what would these rules > be? Isn't this approach "undigesterly"? I mean that "assembly by > discovery" does not really need the digester machinery. digester is just a SAX wrapper. just about anything you can do with SAX=20= you can do using digester. (and that means just about anything.) there are various ways of using digester. this approach certainly goes=20= against the original digester style. digester doesn't have any rules = which=20 are quite as radical as this at the moment but a lot of people seem to = use=20 digester in similar ways using naming patterns and extended wildcards to=20= save writing lots of rules. i tend to use the extended base rules and general pattern based mapping. = i=20 believe that scott has been working on esoteric stuff that is even more=20= liberal. judging from the feedback on the list, most users of digester = are=20 pretty lazy and seem to prefer things to be as automatic as possible. one powerful feature about digester is that it's easy to mix and match=20= different approaches. > Your go learn digester comment is an important one. First, note that > not all components need to interact with the digester, only the more=20= > complex ones. > Second, learning the digester model is not that difficult but given = that=20 > I > find the digester model quite brilliant, my judgement may be somewhat > clouded... :-) brilliant? digester was designed by craig which says it all, i think. this approach probably originates with jason. he was looking for a xml = <->=20 object mapper for turbine. after taking soundings on the turbine lists, = he=20 didn't want a flexible system but rather one that was generic so that = any=20 bean matching certain naming conventions could be mapped. the point was=20= that any coder can quickly learn a set of conventions whereas learning a=20= more flexible - although more powerful - system takes quite a lot = longer. i worked a bit with him on an implementation based on digester a while = ago=20 but unfortunately fighting commons-logging flame wars took all my energy=20= and jason ended up creating a version based on dom4j instead. it's = called=20 xo and it's in the sandbox if you want to take a look. i've been wanting to try and write a rule that provides a digester=20 compatible implementation of jason's heuristics for a while now. betwixt also has some interesting ideas (which since it was dreamed up = by=20 james strachan shouldn't come as a surprise to anyone). this is = primarily=20 an object -> xml mapper which is inspired by the java bean = specification.=20 it uses digester for round tripping (but this isn't very well debugged = at=20 the moment) and so (when it's fixed up) could also be used for automagic=20= xml -> object mapping. i wasn't really advocating using them, i just though that you might find=20= it useful to know the state of the 'current art' (as i see it). - robert -- To unsubscribe, e-mail: For additional commands, e-mail: