logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertdon...@mac.com>
Subject Re: ideas for dynamic configuration
Date Wed, 15 May 2002 19:35:40 GMT
On Wednesday, May 15, 2002, at 11:32 AM, Ceki Gülcü wrote:

> At 22:04 14.05.2002 +0100, you wrote:

<snip>

>> the first strategy is to allow the subcomponents to configure themselves 
>> using bean-like rules. the idea is that the object to be configured must 
>> conform to certain patterns similar to getters and setters for the 
>> xml->object mapping. (xo and betwixt in the commons-sandbox were created 
>> with this philosophy in mind.)
>>
>> this strategy has the advantage of being more secure and offers less 
>> room for configuration conflicts. it's also much easier to explain to an 
>> implementor that these are the rules that their beans need to follow to 
>> make the configuration work properly than it is to say - go learn 
>> 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 
you can do using digester. (and that means just about anything.)

there are various ways of using digester. this approach certainly goes 
against the original digester style. digester doesn't have any rules which 
are quite as radical as this at the moment but a lot of people seem to use 
digester in similar ways using naming patterns and extended wildcards to 
save writing lots of rules.

i tend to use the extended base rules and general pattern based mapping. i 
believe that scott has been working on esoteric stuff that is even more 
liberal. judging from the feedback on the list, most users of digester are 
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 
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 
> complex ones.
> Second, learning the digester model is not that difficult but given that 
> 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 <-> 
object mapper for turbine. after taking soundings on the turbine lists, he 
didn't want a flexible system but rather one that was generic so that any 
bean matching certain naming conventions could be mapped. the point was 
that any coder can quickly learn a set of conventions whereas learning a 
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 
but unfortunately fighting commons-logging flame wars took all my energy 
and jason ended up creating a version based on dom4j instead. it's called 
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 
compatible implementation of jason's heuristics for a while now.

betwixt also has some interesting ideas (which since it was dreamed up by 
james strachan shouldn't come as a surprise to anyone). this is primarily 
an object -> xml mapper which is inspired by the java bean specification. 
it uses digester for round tripping (but this isn't very well debugged at 
the moment) and so (when it's fixed up) could also be used for automagic 
xml -> object mapping.


i wasn't really advocating using them, i just though that you might find 
it useful to know the state of the 'current art' (as i see it).

- robert


--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message