Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [digester] plugins: patch for logging
From: Simon Kitching <simon@ecnetwork.co.nz>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <403D4F8E-099F-11D8-8F75-003065DC754C@blueyonder.co.uk>
References: <403D4F8E-099F-11D8-8F75-003065DC754C@blueyonder.co.uk>
Content-Type: text/plain
Message-Id: <1067388198.9400.58.camel@PCSIMON.ecnnz.ecnetwork.co.nz>
Mime-Version: 1.0
Date: Wed, 29 Oct 2003 13:43:18 +1300
Content-Transfer-Encoding: 7bit

On Wed, 2003-10-29 at 12:34, robert burrell donkin wrote:
> On Monday, October 27, 2003, at 10:17 PM, Simon Kitching wrote:
> 
> > Hi,
> 
> hi simon
> 
> i'm not totally convinced that your patch is the best possible approach 
> but i think that it's an improvement so i've committed it. it's pretty 
> much the baseline required for compatibility with the rest of digester. we 
> need another digester release sometime soonish so maybe this needs 
> thinking about sooner rather than later.

Aha! Good to see that you're thinking about logging too :-)

By the "not convinced" comment, do you mean that I am not complying with
the current Digester conventions correctly, or do you mean that the
current Digester conventions aren't right?

Regarding a new release, I think it would be nice to get something out
before Christmas. I've seen lots of small fixes go in over the last few
months.

Is plugins sufficiently accepted to become part of this new release?
I haven't heard anyone raise any objections to it, or suggest it should
be removed so I hope so.

What I would suggest is:

(a) 
I need to submit patches for:
 (1) Assertion --> RuntimeException (coming today)
 (2) setting attribute which specifies plugin, eg
       <foo classe-de-plugin="..."/>
 (3) A change to the way "autoSetProperties" works.
     I want to have a pluggable "strategy" parameter
     instead of a boolean, for more flexibility.

(b) 
If no-one has any more issues with plugins, I will port my (ECN's)
commercial app over to the new library and run tests.
This will be a good test of both the API and the implementation.
This should take only a day of actual work, but with my current
workload, it will probably take about 1 week elapsed time.

Of course I only want to do this if there is a pretty good chance that
plugins will stay in Digester....

(c) 
Do a release, or release candidate.

Any logging changes (if something can be agreed on) might go in the mix
too.

On a related note, I went through the outstanding digester
bugs/enhancements in buzgilla a while ago and added some comments.
Unfortunately nothing happened. I think that almost all the outstanding
entries can be closed, which would be cool to do before the next
release.


> nothings every finished :)

Good point!

> i've been thinking about this for a little while and i think that i now 
> have some ideas about the way i'd prefer logging to work which should 
> preserve backwards compatibility. (i'd like to put setters and getters for 
> the logs on each class and then set then from parent to child as they are 
> created. )

I'm not sure this will work. In order to have a proper hierarchy of
categories, the same Log object can't just be passed to the child.

I've been thinking about enhancing commons-logging so that a LogFactory
object can be placed in thread-local storage, and the static LogFactory
method will look there first, and delegate if there is one.

For containers which dedicate a thread to a "subsystem", this would
work. For containers which use thread pools, the container would need to
install the correct LogFactory object before using the thread to do work
in a specific contained app. Yes, that's logging-specific work. But so
is calling the setLog method on Digester or similar.

Well, those are just initial thoughts. I was intending to think it
through a bit more before suggesting any ideas, but as you are looking
at logging, I had better put it forward now..

> 
> > As the governor of California would say, "I'll be back".. :-)
> 
> i'll look forward to that. i'd certainly like to encourage you to stay 
> involved with digester.

I'd be happy to. 

Once the new release is out, I would like to start looking at some of
the other apache projects to determine which of them don't use Digester,
and why. Maybe we can then roll extra functionality they need into the
base Digester. In particular, Ceki Gulcu (log4j) has a sandbox project
Joran, which sounds very digester-like. I think it would be great if we
could merge the projects. Any comments?

BTW, I'm currently learning Ruby, and decided to practice by porting
Digester to Ruby. It's coming along very well (and turned out to be an
excellent learning experience). Look for "xmldigester" coming to
RubyForge soon! Any Rubyish types watching this email list are welcome
to join in. I'll post an email here when the code is up, or you can
contact me directly.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org