At 13:23 14.05.2002 -0700, Mark Womack wrote:
> > 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.
Not exactly. The basic rules will be coded within DigesterConfigurator
(pick your own name) not in AppenderSkeleton. The localized rules will
be necessary only for few specialized cases. Every time, a digester
(contained within a DigesterConfigurator) would start configuring a
new component, it would ask it for the rules but only if implemented a
specific interface, say ContainsLocalizedRules, which could look as
follows:
public interface ContainsLocalizedRules {
public Rules getLocalizedRules();
}
The digester would get these localized rules and apply them while it
was configuring this component. It would forget the localized rules
immediately after finishing configuring the component.
>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.
Very interesting observation. The properties format is not rich enough
to support multiple nested components. However, there is no reason why
the JDK 1.4 prefs could not be handled by a digester-like model.
ContainsLocalizedRules interface would become:
public interface ContainsLocalizedRules {
public XMLRules getLocalizedRulesForXML();
public PrefRules getgetLocalizedRulesForPref();
}
Another alternative is to keep ContainsLocalizedRules as is (one
method only) but enhance the contents of Rules. To be more specific,
Rules would be a bag of Rule objects where a Rule is the association
of a pattern with an XMLAction and also PrefsAction.
Also, please see the discussion about Action versus Rule in
http://marc.theaimsgroup.com/?t=102137752700001&r=1&w=2
As I wrote in a previous mail, I will not have the time to code the
log4j digester clone until the end of this month. My offer to code
this critical piece of code still stands.
--
Ceki
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
