At 22:00 16.05.2002 +0100, robert burrell donkin wrote: <snip> >>Yes, I have given it some thought. Although the hierarchical rules >>extension of the digester model is cool (hey it's my idea), I am trying >>to find ways of sticking to the original digester model and not >>introducing hierarchical Rules (i.e. o.a.c.digester.Rules). I'll be sure >>to look at betwixt and xo. Thanks for the pointers by the way. > >i think that maybe we are a bit at cross purposes here. (though your >comments were interesting.) > >i was talking about the 'Rules' architecture. these are more correctly >pattern matching rules. 'Rules' implementations are used to return a list >of rule's that match a given element pattern. > >i'm a bit confused by what you mean by hierarchical rules. do you mean >that self-configuring extension that you proposed earlier? (the more i >have to talk about digester to you, the more i think that the digester >nomenclature is holding the component back.)
Here is a thread of thought: The decisive advantage of the digester model is that one can introduce rules dynamically. In the log4j case, I would like some advanced components that need intricate configuration to inform the DigesterConfigurator (a new log4j configurator) of the steps required to configure it properly. Let XAppender be such a complex component. The rules, (a rule is the association of a pattern and an action) for XAppender are searched in a class called XAppenderXMLRules. So far so good except that in a given configuration file might contain multiple instances of XAppender. Thus, we must find a way to avoid adding the same rules multiple times to the rule set that DigesterConfigurator uses. (I do not make a distinction between Rules and RuleSets. They both contains rules and can do matching, at least in the scope of this discussion.) One way of making sure that a custom rule set is used only once, is to add it and remove it immediately after the custom component is configured. The problem is that custom components might require other custom components, hence the need for hierarchical rule sets. Hmm, it's actually more a rules *stack*. Another way to avoid adding custom rules more than once is to keep track of the rules that were already added. A hashmap in DigesterConfigurator can keep track of the classes for which rules that have been already loaded and avoid loading them multiple times. It might get pretty hairy if you start considering subclasses of XAppender. >- robert -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
