You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by robert burrell donkin <ro...@mac.com> on 2002/05/14 19:30:34 UTC
Re: Interesting thread about commons-digester and other component s
On Monday, May 13, 2002, at 10:57 PM, Ceki Gülcü wrote:
> At 14:23 13.05.2002 -0700, Mark Womack wrote:
>> > >1) I do think that having a "special" version of the
>> > digester is going to be
>> > >a long-term headache.
>> >
>> > The issue is more social than technical. Unless there is a
>> > good reason to
>> > do it, it's pretty uncool to rip off someone else's code.
>> > Fortunately, in this
>> > case the authors have been very kind to grant permission to
>> > use and modify
>> > their code which somewhat mitigates my/our guilt.
>>
>> Actually, I am not so worried about the social issues. I am more worried
>> about what happens when bug fixes are applied to the original digester
>> code.
>> Are we going to spend time moving the latest changes over into the log4j
>> version? Or are we going to make sure the log4j version works for our
>> needs
>> and "freeze" it, not making any changes to it unless absolutely required.
>> Maintaining this code long-term is more the issue I am talking about.
>
> The core of the digester code, if you look at it carefully is actually
> surprisingly simple, at least in versions 1.0 and 1.1. I do not forsee
> any serious maintenance issues although one can only be sure after
> actually writing the code.
my main worry from a technical point of view would be about beanutils. you'
ll find it very difficult to decouple digester from beanutils and have
anything let that's viable. i'm pretty confident that the core digester
stuff is pretty well debugged - but i do have worries about beanutils.
in terms of maintainability, it all depends on how you do it.
obviously you'd need to repackage digester and beanutils, and you'd want
to drop any unused classes. one way that you could reduce maintenance to a
minimum would be to create classes with the same signatures as the
interface and class that digester relies upon from commons-logging and
then just substitute the names in the import.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interesting thread about commons-digester and other
component s
Posted by Ceki Gülcü <ce...@qos.ch>.
At 22:00 16.05.2002 +0100, robert burrell donkin wrote:
<snip>
>>Yes, I have given it some thought. Although the hierarchical rules
>>extension of the digester model is cool (hey it's my idea), I am trying
>>to find ways of sticking to the original digester model and not
>>introducing hierarchical Rules (i.e. o.a.c.digester.Rules). I'll be sure
>>to look at betwixt and xo. Thanks for the pointers by the way.
>
>i think that maybe we are a bit at cross purposes here. (though your
>comments were interesting.)
>
>i was talking about the 'Rules' architecture. these are more correctly
>pattern matching rules. 'Rules' implementations are used to return a list
>of rule's that match a given element pattern.
>
>i'm a bit confused by what you mean by hierarchical rules. do you mean
>that self-configuring extension that you proposed earlier? (the more i
>have to talk about digester to you, the more i think that the digester
>nomenclature is holding the component back.)
Here is a thread of thought:
The decisive advantage of the digester model is that one can introduce
rules dynamically. In the log4j case, I would like some advanced components
that need intricate configuration to inform the DigesterConfigurator (a new
log4j configurator) of the steps required to configure it properly. Let
XAppender be such a complex component. The rules, (a rule is the
association of a pattern and an action) for XAppender are searched in a
class called XAppenderXMLRules. So far so good except that in a given
configuration file might contain multiple instances of XAppender. Thus, we
must find a way to avoid adding the same rules multiple times to the rule
set that DigesterConfigurator uses. (I do not make a distinction between
Rules and RuleSets. They both contains rules and can do matching, at least
in the scope of this discussion.)
One way of making sure that a custom rule set is used only once, is to add
it and remove it immediately after the custom component is configured. The
problem is that custom components might require other custom components,
hence the need for hierarchical rule sets. Hmm, it's actually more a rules
*stack*.
Another way to avoid adding custom rules more than once is to keep track of
the rules that were already added. A hashmap in DigesterConfigurator can
keep track of the classes for which rules that have been already loaded and
avoid loading them multiple times. It might get pretty hairy if you start
considering subclasses of XAppender.
>- robert
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interesting thread about commons-digester and other component s
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, May 16, 2002, at 09:12 PM, Ceki Gülcü wrote:
> At 20:28 16.05.2002 +0100, you wrote:
<snip>
>> you're not bothered about not supporting the most popular digester rules
>> since you'd expect people to creating their own custom rules.
>
> Yes. I find it much quicker and safer to write a new Action
> (o.a.c.digester.Rule) in just a few lines of java than writing multiple
> pattern/rule pairs using the standard rules but that's just me.
i sometimes feel the same. i like using anonymous classes. where the
existing rules come into there own is with complex xml mappings. they
allow more concise rules sets for large mappings. when you've got dozen's
of classes and elements to map, smaller, more powerful rulesets start to
come into their own.
but since in this context we're dealing with configuration and therefore
smaller mappings, it makes a lot more sense to push users into creating
new rules. complex rulesets using the generic rules are very powerful but
also rather arcane and pretty hard to debug. you're probably going to save
a lot of grief in the long run by persuading people to adopt your approach.
<snip>
>> have you thought about what you're going to do about patten matching
>> rules?
>
> Yes, I have given it some thought. Although the hierarchical rules
> extension of the digester model is cool (hey it's my idea), I am trying
> to find ways of sticking to the original digester model and not
> introducing hierarchical Rules (i.e. o.a.c.digester.Rules). I'll be sure
> to look at betwixt and xo. Thanks for the pointers by the way.
i think that maybe we are a bit at cross purposes here. (though your
comments were interesting.)
i was talking about the 'Rules' architecture. these are more correctly
pattern matching rules. 'Rules' implementations are used to return a list
of rule's that match a given element pattern.
i'm a bit confused by what you mean by hierarchical rules. do you mean
that self-configuring extension that you proposed earlier? (the more i
have to talk about digester to you, the more i think that the digester
nomenclature is holding the component back.)
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interesting thread about commons-digester and other
component s
Posted by Ceki Gülcü <ce...@qos.ch>.
At 20:28 16.05.2002 +0100, you wrote:
>On Wednesday, May 15, 2002, at 10:04 PM, Ceki Gülcü wrote:
>
><snip>
>
>>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?
>
>yes i think so.
>
>you plan to use only the digester engine and then create your own custom
>rules. these custom rules are going to use internal log4j introspection
>code (where needed) and therefore won't require beanutils.
A rather primitive version of beanutils can be found at
org.apache.log4j.config.
>you're not bothered about not supporting the most popular digester rules
>since you'd expect people to creating their own custom rules.
Yes. I find it much quicker and safer to write a new Action
(o.a.c.digester.Rule) in just a few lines of java than writing multiple
pattern/rule pairs using the standard rules but that's just me.
>is this a fair summary?
Yes.
>have you thought about what you're going to do about patten matching rules?
Yes, I have given it some thought. Although the hierarchical rules
extension of the digester model is cool (hey it's my idea), I am trying to
find ways of sticking to the original digester model and not introducing
hierarchical Rules (i.e. o.a.c.digester.Rules). I'll be sure to look at
betwixt and xo. Thanks for the pointers by the way.
>on a different track, i suppose the one advantage of using a completely
>rewritten digester is that you can use those improved names with fear of
>breaking backwards compatibility.
:-)
>- robert
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interesting thread about commons-digester and other component s
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, May 15, 2002, at 10:04 PM, Ceki Gülcü wrote:
<snip>
> 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?
yes i think so.
you plan to use only the digester engine and then create your own custom
rules. these custom rules are going to use internal log4j introspection
code (where needed) and therefore won't require beanutils.
you're not bothered about not supporting the most popular digester rules
since you'd expect people to creating their own custom rules.
is this a fair summary?
have you thought about what you're going to do about patten matching rules?
on a different track, i suppose the one advantage of using a completely
rewritten digester is that you can use those improved names with fear of
breaking backwards compatibility.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interesting thread about commons-digester and other
component s
Posted by Ceki Gülcü <ce...@qos.ch>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interesting thread about commons-digester and other component s
Posted by robert burrell donkin <ro...@mac.com>.
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.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interesting thread about commons-digester and other component s
Posted by Ceki Gulcu <ce...@yahoo.com>.
--- robert burrell donkin <ro...@mac.com>
wrote:
>
> On Monday, May 13, 2002, at 10:57 PM, Ceki G�lc�
> wrote:
>
> > At 14:23 13.05.2002 -0700, Mark Womack wrote:
> >> > >1) I do think that having a "special" version
> of the
> >> > digester is going to be
> >> > >a long-term headache.
> >> >
> >> > The issue is more social than technical. Unless
> there is a
> >> > good reason to
> >> > do it, it's pretty uncool to rip off someone
> else's code.
> >> > Fortunately, in this
> >> > case the authors have been very kind to grant
> permission to
> >> > use and modify
> >> > their code which somewhat mitigates my/our
> guilt.
> >>
> >> Actually, I am not so worried about the social
> issues. I am more worried
> >> about what happens when bug fixes are applied to
> the original digester
> >> code.
> >> Are we going to spend time moving the latest
> changes over into the log4j
> >> version? Or are we going to make sure the log4j
> version works for our
> >> needs
> >> and "freeze" it, not making any changes to it
> unless absolutely required.
> >> Maintaining this code long-term is more the issue
> I am talking about.
> >
> > The core of the digester code, if you look at it
> carefully is actually
> > surprisingly simple, at least in versions 1.0 and
> 1.1. I do not forsee
> > any serious maintenance issues although one can
> only be sure after
> > actually writing the code.
>
> my main worry from a technical point of view would
> be about beanutils. you'
> ll find it very difficult to decouple digester from
> beanutils and have
> anything let that's viable. i'm pretty confident
> that the core digester
> stuff is pretty well debugged - but i do have
> worries about beanutils.
First, log4j does not need to implement all the Rules
that digester-commons has. Second, we can implement
rules for setting properties, i.e SetPropertyRule,
with our *existing* capability to set parameters. As
for SetPropertiesRule (note the plural) it would be
nice to have but certainly not crucial.
> in terms of maintainability, it all depends on how
> you do it.
>
> obviously you'd need to repackage digester and
> beanutils, and you'd want
> to drop any unused classes. one way that you could
> reduce maintenance to a
> minimum would be to create classes with the same
> signatures as the
> interface and class that digester relies upon from
> commons-logging and
> then just substitute the names in the import.
> - robert
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.
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>