Ceki,
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
accomplish?
-Mark
> >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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
