At 20:02 15.05.2002 +0100, you wrote:
>On Wednesday, May 15, 2002, at 09:52 AM, Ceki Gulcu wrote:
>
><snip>
>
>>I have been studying the digester code quite
>>carefully. My conclusion is that as long we do not try
>>to be fancy and if our clone will be for log4j
>>"internal" use only, then we can make many
>>simplifications. It will be an interesting excercise
>>but without glory whatsoever.

>there's one thing that i don't quite see...
>
>if you want to use digester to allow the configuration to be extended at 
>run time, by removing rules from the private version you're also be 
>preventing people from using them for their extended configurations. 
>judging from the questions i've fielded on the list, the rules which use 
>introspection are amongst the most popular with users so removing them 
>could significantly reduce the utility of this feature.
>
>of course, a possible solution would be to have two jars. the first would 
>be a stripped down digester version containing just the digester engine 
>and the rules you need for standard log4j configuration. the second would 
>contain extra rules for use by configuration extensions.

My use of the word "internal" was misleading. The whole exercise is about 
allowing users to come with new actions and rules for configuring their 
components. What I am saying is that we (log4j) already has the capability 
to set parameters using introspection. We do not need beanutils.

Searching for places where beanutils is used:

/jakarta-commons/digester#    find  src/ -name "*.java"|xargs grep -i beanutils

src/java/org/apache/commons/digester/BeanPropertySetterRule.java:import 
org.apache.commons.beanutils.BeanUtils;
src/java/org/apache/commons/digester/BeanPropertySetterRule.java:        // 
going to use beanutils so need to specify property using map
src/java/org/apache/commons/digester/BeanPropertySetterRule.java: 
BeanUtils.populate(top, map);
src/java/org/apache/commons/digester/CallMethodRule.java:import 
org.apache.commons.beanutils.ConvertUtils;
src/java/org/apache/commons/digester/CallMethodRule.java:import 
org.apache.commons.beanutils.MethodUtils;
src/java/org/apache/commons/digester/SetNextRule.java:import 
org.apache.commons.beanutils.MethodUtils;
src/java/org/apache/commons/digester/SetNextRule.java:     * <p>This rule 
uses <code>org.apache.commons.beanutils.MethodUtils</code>
src/java/org/apache/commons/digester/SetPropertiesRule.java:import 
org.apache.commons.beanutils.BeanUtils;
src/java/org/apache/commons/digester/SetPropertiesRule.java: 
BeanUtils.populate(top, values);
src/java/org/apache/commons/digester/SetPropertyRule.java:import 
org.apache.commons.beanutils.BeanUtils;
src/java/org/apache/commons/digester/SetPropertyRule.java: 
BeanUtils.populate(top, values);
src/java/org/apache/commons/digester/SetRootRule.java:import 
org.apache.commons.beanutils.MethodUtils;
src/java/org/apache/commons/digester/SetRootRule.java:     * <p>This rule 
uses <code>org.apache.commons.beanutils.MethodUtils</code>
src/java/org/apache/commons/digester/SetTopRule.java:import 
org.apache.commons.beanutils.MethodUtils;
src/java/org/apache/commons/digester/SetTopRule.java:     * <p>This rule 
uses <code>org.apache.commons.beanutils.MethodUtils</code>

We almost certainly do not need BeanPropertySetterRule in any case its a 
variant of SetPropertyRule. As for SetTopRule, SetRootRule, SetNextRule, 
CallMethodRule, although very generic, imho they make it harder to follow 
and understand rule sets. I always try to avoid using them.

Does my claim about not needing beanutils in log4j make more sense now?

--
Ceki


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to