At 22:04 14.05.2002 +0100, you wrote: >On Tuesday, May 14, 2002, at 02:00 PM, Ceki Gülcü wrote: > ><snip> > >>2) Within the component being configured. >> >>The component being configured informs the digester about the >>additional rules it needs. These rules are applied only while the >>component is being processed (configured). They are removed just after >>the processing of that particular component finishes. >> >>This approach would require changes in the commons-digester >>model. Instead of having a single set of rules, the set of rules would >>be hierarchical. There would always be the global set of rules at the >>top. One ore more child rule-sets (defined by the components) would be >>added/removed according to interactions with the components. The >>search for patterns would proceed from child to parent rule-sets. >> >>This is perhaps an overkill for log4j but I think it could be useful >>in more complicated scenarios. > >by a strange piece of synchronicity, functionality along these lines was >one reason i was going to give for trying to keep the version of digester >used by log4j as close to the base code as possible :) > >this is something for which there has been a need for a while now. there >are two general approaches to the problem that i'm aware of. > >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. 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... :-) >the other strategy (as ceki outlined above) is to allow objects to supply >the rules required to allow mapping by digester. we've had a patch sitting >around for a long time now which offers an implementation. it has some >good points but AFAIK it hasn't been committed. i originally had some >reservations about it's design but i did eventually get back to the >original author offering to commit it if he still felt strongly enough >about it. ceki's outlined implementation is much more like the way i'd >prefer to see it done. The problem with my suggestion is that it requires some low level changes to the digester code as much as the digester model. This increases the complexity of the code. Another problem with the localized rules approach is that digester learns new rules only to forget them a little while later. There are probably simpler ways to learn about new rules. For example, we could have them stored in an XML file and have them parsed with DigesterLoader or some other similar mechanism. See for example the org.apache.commons.digester.xmlrules package. >the major advantage of this approach is that it is powerful and flexible. It also requires low level changes to the existing digester model which is a disadvantage. By the way, I will not have the time to work on this for a couple of weeks. If anyone else wants to start coding this very critical piece, they are welcome to it, as long as they are open to code reviews. :-) -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
