At 11:35 15.05.2002 -0700, Mark Womack wrote:
>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?
Here is an idea. How about having components have another class which
contains info about rules for configuring them. For example,
SMTPAppenderXMLRules contains rules for configuring the SMTPAppender,
when we have a digester for util.prefs we could simply add
SMTPAppenderPrefsRules to log4j.jar.
>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?
True, the trick is to come up with these rules. I frankly don't think
it's possible though I'd love to be proven wrong. :-)
>-Mark
--
Ceki
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
