On Mon, 2006-01-09 at 14:47 -0800, Mark Womack wrote:
>
>
> My question before was if you were suggesting a different set of "fine
> grain" classes that co-exist with the current set of classes?
That was my preferred approach. Adding "fine grained" locking to
AppenderSkeleton seems entirely imp
Curt is right. Submitting a CLA and resubmitting the code with proper
ASF headers, etc should be sufficient.
See this link, under "Contributor License Agreements":
http://www.apache.org/licenses/
My question before was if you were suggesting a different set of "fine
grain" classes that co-exist
On Jan 9, 2006, at 10:29 AM, Elias Ross wrote:
On Fri, 2005-12-23 at 22:22 -0600, Curt Arnold wrote:
I haven't taken a serious look at the code. But if all the IP issues
are addressed and there are no objections, I'd have no problem having
the contribution in the sandbox. If it then progres
On Fri, 2005-12-23 at 22:22 -0600, Curt Arnold wrote:
> I haven't taken a serious look at the code. But if all the IP issues
> are addressed and there are no objections, I'd have no problem having
> the contribution in the sandbox. If it then progresses to something
> that the community wa
Cc: "Curt Arnold" <[EMAIL PROTECTED]>
Sent: Friday, December 23, 2005 4:37 PM
Subject: Re: log4j 1.3 prioritized tasks
On Thu, 2005-12-22 at 00:46 -0600, Curt Arnold wrote:
I'd prefer to expedite the 2.0 branch and get log4j using a much
finer grained locking than maintain
Jacob Kjome" <[EMAIL PROTECTED]>
To: "Log4J Developers List"
Sent: Saturday, December 24, 2005 9:39 AM
Subject: Re: log4j 1.3 prioritized tasks
At 06:10 PM 12/23/2005 -0600, you wrote:
>
>On Dec 23, 2005, at 3:37 PM, Jacob Kjome wrote:
>
>>
>> A bi
On Fri, 23 Dec 2005, Jacob Kjome wrote:
|
| A bit of a sidetrack from the current discussion, but just how big is
| log4j-1.3 going to be and just how polluted with 1.2.xx stuff are we going to
| make it? Originally, a lot of stuff was refactored and/or removed and
| replaced by, arguably, bette
At 06:10 PM 12/23/2005 -0600, you wrote:
>
>On Dec 23, 2005, at 3:37 PM, Jacob Kjome wrote:
>
>>
>> A bit of a sidetrack from the current discussion, but just how big
>> is log4j-1.3 going to be and just how polluted with 1.2.xx stuff
>> are we going to make it? Originally, a lot of stuff was ref
On Dec 23, 2005, at 6:37 PM, Elias Ross wrote:
On Thu, 2005-12-22 at 00:46 -0600, Curt Arnold wrote:
I'd prefer to expedite the 2.0 branch and get log4j using a much
finer grained locking than maintaining two parallel sets of appenders
with different locking characteristics.
I'd be happy to
On Thu, 2005-12-22 at 00:46 -0600, Curt Arnold wrote:
> I'd prefer to expedite the 2.0 branch and get log4j using a much
> finer grained locking than maintaining two parallel sets of appenders
> with different locking characteristics.
I'd be happy to help expedite a 2.0 release, but it seems
On Dec 23, 2005, at 3:37 PM, Jacob Kjome wrote:
A bit of a sidetrack from the current discussion, but just how big
is log4j-1.3 going to be and just how polluted with 1.2.xx stuff
are we going to make it? Originally, a lot of stuff was refactored
and/or removed and replaced by, arguably
Hi,
> thoughts?
As a team, we're split between wanting binary compatibility at all
costs and wanting to move forward with a cleaner, leaner log4j with
new features that don't necessarily maintain that compatibility.
Because the people who care about backwards compatibility are more
active in bot
A bit of a sidetrack from the current discussion, but just how big is
log4j-1.3 going to be and just how polluted with 1.2.xx stuff are we going
to make it? Originally, a lot of stuff was refactored and/or removed and
replaced by, arguably, better implementations. Last changes I made, I had
I was pretty tired last night, so maybe my reaction as "shameful" was
a little much. But I still believe there is a lot of room for
improvement that needs to be done.
If you look at the documentation we have, there is the short
introduction (which is old and needs some updating; it doesn't even
t
Hola,
> biased view. But I don't agree with the documentation. We REALLY need to
> do something. I think our current state is pretty shameful.
I only bundled them together because one of the reasons for moving to
Maven is improved documentation.
> I'd like to
> get more community involvement,
On Dec 21, 2005, at 11:36 PM, Elias Ross wrote:
On Wed, 2005-12-21 at 21:09 -0600, Curt Arnold wrote:
- Locking/threading/synchronization issues
I think it will be difficult or impossible to safely address the
"locks when trying to log during a toString() call" without
potentially breaking
On Wed, 2005-12-21 at 21:09 -0600, Curt Arnold wrote:
>
> > - Locking/threading/synchronization issues
>
> I think it will be difficult or impossible to safely address the
> "locks when trying to log during a toString() call" without
> potentially breaking somebody else. It is an undesirable
http://wiki.apache.org/logging-log4j/Log4j13PrioritizedTasks
- Original Message -
From: "Yoav Shapira" <[EMAIL PROTECTED]>
To: "Log4J Developers List"
Sent: Wednesday, December 21, 2005 6:29 PM
Subject: Re: log4j 1.3 prioritized tasks
Perhaps this prioriti
riginal Message -
From: "Paul Smith" <[EMAIL PROTECTED]>
To: "Log4J Developers List"
Sent: Wednesday, December 21, 2005 6:32 PM
Subject: Re: log4j 1.3 prioritized tasks
On 22/12/2005, at 1:29 PM, Yoav Shapira wrote:
Hi,
I'm OK with this prioritation except for
On Dec 21, 2005, at 8:21 PM, Mark Womack wrote:
I prioritized the task list from the previous thread. Not all of
these are dependent on each other, but I beleive that we should look
at completing the first 2 before seriously tackling anything else.
The last 4 could happen in any order and most
On 22/12/2005, at 1:29 PM, Yoav Shapira wrote:
Hi,
I'm OK with this prioritation except for one thing: build changes
should be just about last, or possibly 2nd to last together with
documentation, as they are a pure enhancement and not a must-have by
any stretch.
+1 build + site work right n
Hi,
I'm OK with this prioritation except for one thing: build changes
should be just about last, or possibly 2nd to last together with
documentation, as they are a pure enhancement and not a must-have by
any stretch.
Perhaps this prioritized list belongs on a wiki page where we can
jointly edit it
I prioritized the task list from the previous thread. Not all of
these are dependent on each other, but I beleive that we should look
at completing the first 2 before seriously tackling anything else.
The last 4 could happen in any order and most likely in parallel.
Documentation will get setup
23 matches
Mail list logo
