On Tue, 3 Jan 2006, Mark Womack wrote:
| If I understand you right, this is what I am planning to do.
|
| The new Plugin/Watchdog functionality splits the whole "watch" stuff
| into a different heirarchy of classes that perform the watching stuff.
| In the process it becomes much more flexible a
If I understand you right, this is what I am planning to do.
The new Plugin/Watchdog functionality splits the whole "watch" stuff
into a different heirarchy of classes that perform the watching stuff.
In the process it becomes much more flexible and controllable and can
now "watch" lots of differ
On Mon, 2 Jan 2006, Mark Womack wrote:
| I was looking at this class in regards to compatibility with 1.2. I was
| interested in restoring the configureAndWatch methods.
I personally truly dislike libraries that fork threads as a "side effect"
of invoking "some random method", or even worse ju
th each release.
-Mark
- Original Message -
From: "Curt Arnold" <[EMAIL PROTECTED]>
To: "Log4J Developers List"
Sent: Monday, January 02, 2006 7:52 PM
Subject: Re: [COMPATIBILITY] DOMConfigurator
On Jan 2, 2006, at 8:07 PM, Paul Smith wrote:
I'd be ok w
On Jan 2, 2006, at 8:07 PM, Paul Smith wrote:
I'd be ok with this being one of the binary compatibility
breakages. I don't believe there would be too many people that had
extended from DOMConfigurator.
I'm okay with it too, at least for this iteration. I assume that
we'd both like th
I'd be ok with this being one of the binary compatibility breakages.
I don't believe there would be too many people that had extended from
DOMConfigurator.
Paul
On 03/01/2006, at 1:00 PM, Mark Womack wrote:
I was looking at this class in regards to compatibility with 1.2.
I was intereste
I was looking at this class in regards to compatibility with 1.2. I was
interested in restoring the configureAndWatch methods. This should be easy
to do and just have them use the new Plugin code to provide the same
functionality, but better because now the watchers can be shutdown properly
o
