> 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.
Ceki, So, how would you envision this working? Taking appenders as an example, I am thinking that there would be a default set of valid rules defined by the base class (AppenderSkeleton). Subclasses of the appender base class will be allowed to add their custom rules to this set. There would be a public method that the configurator/digester would call to get the set of rules to apply, and the configurator would handle the hiearchical nature, as you mentioned. But, doesn't this mean that we are moving xml specific/related code into every component that is configurable? It will no longer be centralized in the log4j/xml/* package. I don't think any of this code will be reusable in the properties file use case. Is this desirable? Me, I love xml, and I don't use the property configuration file format, but I think a lot of other developers do. It would be nice if there was a way to support a generic format that could work for both or even other configuration formats. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
