logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <mwom...@bevocal.com>
Subject RE: ideas for dynamic configuration
Date Wed, 15 May 2002 18:35:15 GMT

To me your example illustrates the problem I am trying to point out.  Now it
is not just xml-specific code that is being moved into the components, but
configurator-specific code that is being moved there.  If Joe Cool developer
writes a new configurator that requires new types of rules, how are the
existing components supposed to know about them without code modification?

I think that the configuration specific code should remain in the
configurator code and not get spread out amongst the rest of the code.  I
don't know what that means for using digester, etc.  But I think there will
be a long-term problem of supporting different configuration file formats.
It seems to me that defining a coherent, understandable set of
introspection/discovery rules that can be used during configuration to call
the correct component methods would be better.  They could be used by any
configurator, their definition/structure would be independent of any single
configurator, and if well designed could support components unknown at the
time the library was released.  Which I think is what we are trying to


> >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.

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message