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. 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 major advantage of this approach is that it is powerful and flexible. of course, these strategies are not necessarily exclusive. digester is certainly flexible enough to allow rules to implement either strategy. - robert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
