failure notice

anyway, the interesting thing is the problem I have fixing Velocity so
Gump is happy ...

Niclas Hedhman informed us of this problem. There was a conscious choice to
remove the old RollingAppender and replace with something better.

Gump is just a fuzzy user ;o)
So irregardless of that, how come this mainly incompatible change is being
made in a .x release?
Wouldn't it be so much better to keep the old RFA still in there with a
massive deprecated sign (possibly in the outputs as well), for one cycle?
Even better if the older one delegates to the newer one, but that is less
important...

As the HEAD now is, you are asking an enormous amount of people to make
changes if they want to upgrade to a newer version, which on paper (if anyone
ever believes the Dewey convention) says it is a compatible upgrade with more
features.

But, then again, I am perhaps too sensitive and lazy, to see the beauty of
culling the class without warning.

Cheers
Niclas

--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+

Ceki Gülcü

2004-11-30 14:47:39 UTC

Niclas,

If we had Microsoft's resources, then we'd follow your advice. But we are
not Microsoft. It's a simple question of resource allocation.

As a user you can either blow this incident out of proportion or accept it
as a minor backward compatibility break which can be easily fixed when
log4j 1.3 is released. However, cognizant of the delicate situation, we
make no noises or announcements about any of the alpha releases of 1.3.

Post by Niclas Hedhman
Gump is just a fuzzy user ;o)
So irregardless of that, how come this mainly incompatible change is being
made in a .x release?
Wouldn't it be so much better to keep the old RFA still in there with a
massive deprecated sign (possibly in the outputs as well), for one cycle?
Even better if the older one delegates to the newer one, but that is less
important...
As the HEAD now is, you are asking an enormous amount of people to make
changes if they want to upgrade to a newer version, which on paper (if anyone
ever believes the Dewey convention) says it is a compatible upgrade with more
features.
But, then again, I am perhaps too sensitive and lazy, to see the beauty of
culling the class without warning.
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------

--
Ceki Gülcü

The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport

Geir Magnusson Jr

2004-11-30 13:58:42 UTC

some lists choose to moderate...

Hello Geir,
We currently don't but may switch back to moderated list. Sorry about
the hassle.

anyway, the interesting thing is the problem I have fixing Velocity
so Gump is happy ...

Niclas Hedhman informed us of this problem. There was a conscious
choice to remove the old RollingAppender and replace with something
better.

That's all well and good, but why not deprecate for a version?

Post by Ceki GÃ¼lcÃ¼
To help you solve this problem there several routes exists. First and
more philosophically, there is more to software development than
keeping gump happy.

This is true. 100%

But what gump has done here is given us early warning that if one of us
doesn't do something, Velocity users [and every other log4j user using
RollingFileAppender] are *screwed* if they try to upgrade a minor
version number of log4j, to 1.3.

Post by Ceki GÃ¼lcÃ¼
Having said that, you can keep gump happy by either switching to
FileAppender or keep your own version of RollingFileAppender.

If I switch to FileAppender, then the software won't behave the same
(right?) or yes, I can take the RollingFileAppender code from you and
put in Velocity, but I think that's suboptimal :)

What I want is that existing velocity users can upgrade to log4j 1.3
w/o hassle.

Post by Ceki GÃ¼lcÃ¼
Perhaps the easiest alternative is to have velocity explicitly tell
gump that velocity depends on log4j 1.2.x and not log4j head. Actually
this would be he action I would recommended.

But forgetting Gump, in general, what do you want me and other users to
do? have to modify our code to update to 1.3?

geir

Post by Ceki GÃ¼lcÃ¼
I hope this helps,

Date: November 29, 2004 9:29:02 PM EST
Subject: failure notice
Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
Sorry, only subscribers may post. If you are a subscriber, please
your new address included (#5.7.2)
--- Below this line is a copy of the message.
Received: (qmail 13066 invoked by uid 99); 30 Nov 2004 02:29:02 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from chi.mobile-health-diary.com (HELO
chi.mobile-health-diary.com) (128.241.244.71)
by apache.org (qpsmtpd/0.28) with SMTP; Mon, 29 Nov 2004 18:29:02 -0800
Received: (qmail 11965 invoked from network); 30 Nov 2004 02:29:00 -0000
Received: from ool-43560634.dyn.optonline.net (HELO ?10.0.1.2?)
by b014.internal.mobile-health-diary.com with SMTP; 30 Nov 2004
02:29:00 -0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes;
format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: Gump reporting
Date: Mon, 29 Nov 2004 21:28:57 -0500
X-Mailer: Apple Mail (2.619)
X-Virus-Checked: Checked
Why isn't this backwards compatible?
I'm trying to fix this, but I can't. There is no released version of =20=
log4j that has this change, and I won't have vel based on whatever we =20=
can build from head-du-jour.
Is there a way to make this backwards compatible? Like deprecate =20
o.a.l.RFA, release so we can switch to o.a.l.rolling.RFA?
geir

But how do you constrain the use of disk space with the
FileAppender?
With the RollingFileAppender, that is a simple matter of =

configuration.

Regards,
Paulo Gaspar

Hi Niclas,
The change is not not a backward compatible. My suggestion would be =20=
use a simple FileAppender instead of RollingFileAppender.

--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport

--
Geir Magnusson Jr +1-203-665-6437
***@gluecode.com

Ceki Gülcü

2004-11-30 14:32:06 UTC

some lists choose to moderate...

Hello Geir,
We currently don't but may switch back to moderated list. Sorry about the
hassle.

anyway, the interesting thing is the problem I have fixing Velocity so
Gump is happy ...

Niclas Hedhman informed us of this problem. There was a conscious choice
to remove the old RollingAppender and replace with something better.

That's all well and good, but why not deprecate for a version?

Because the old RollingAppender has bugs. Consequently, we don't want to
make it available to Mrs. Piggy in the next version of log4j 1.3.

Post by Geir Magnusson Jr
But what gump has done here is given us early warning that if one of us
doesn't do something, Velocity users [and every other log4j user using
RollingFileAppender] are *screwed* if they try to upgrade a minor version
number of log4j, to 1.3.
What I want is that existing velocity users can upgrade to log4j 1.3 w/o
hassle.

Log4j 1.3 is currently in alpha. Ignore 1.3 until it goes RC. When it goes
RC, switch to 1.3. It should be trivial to do so.

Post by Geir Magnusson Jr
But forgetting Gump, in general, what do you want me and other users to
do? have to modify our code to update to 1.3?

Wait, don't do anything for the time being. Velocity ships with a copy
log4j doesn't it? Continue to ship log4j 1.2.9 until you decide to switch
to 1.3, for example when it goes RC. Switching velocity to use log4j 1.3
instead of 1.2 should be pretty easy to do.

How does that sound?

--
Ceki Gülcü

The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport

Geir Magnusson Jr

2004-11-30 14:50:09 UTC

some lists choose to moderate...

Hello Geir,
We currently don't but may switch back to moderated list. Sorry
about the hassle.

anyway, the interesting thing is the problem I have fixing Velocity
so Gump is happy ...

Niclas Hedhman informed us of this problem. There was a conscious
choice to remove the old RollingAppender and replace with something
better.

That's all well and good, but why not deprecate for a version?

Because the old RollingAppender has bugs. Consequently, we don't want
to make it available to Mrs. Piggy in the next version of log4j 1.3.

Mrs. Piggy?

Can you make o.a.l.RFA be an adapter for o.a.l.rolling.RFA?

Post by Geir Magnusson Jr
But what gump has done here is given us early warning that if one of
us doesn't do something, Velocity users [and every other log4j user
using RollingFileAppender] are *screwed* if they try to upgrade a
minor version number of log4j, to 1.3.
What I want is that existing velocity users can upgrade to log4j 1.3
w/o hassle.

Log4j 1.3 is currently in alpha. Ignore 1.3 until it goes RC. When it
goes RC, switch to 1.3. It should be trivial to do so.

It is, but requires a code change. For people with code in production,
asking to do a code change to upgrade log4j is asking a lot.

Post by Geir Magnusson Jr
But forgetting Gump, in general, what do you want me and other users
to do? have to modify our code to update to 1.3?

Wait, don't do anything for the time being. Velocity ships with a copy
log4j doesn't it?

no, we just tell people that we have a logger that writes to it.

Post by Ceki GÃ¼lcÃ¼
Continue to ship log4j 1.2.9 until you decide to switch to 1.3, for
example when it goes RC. Switching velocity to use log4j 1.3 instead
of 1.2 should be pretty easy to do.
How does that sound?

We don't ship log4j. We support having velocity log to a whole bunch
of things, log4j being one of them (and probably the most popular...)

geir

--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport

--
Geir Magnusson Jr +1-203-665-6437
***@gluecode.com

Eric Pugh

2004-11-30 16:04:41 UTC

Jar upgrades are never easy. I would venture a guess that in Log4j world,
1.3 is the equvalent of 2.0 in other projects. Especially if you count how
many 1.2.x releases there where..

The worst thing that can happen is that the o.a.l.RFA class is grabbed out
of log4j just to provide the compatiblity. I hate that when I have
hibernate.jar and commons-lang.jar that eclipse prompts me for which path to
import from for my NestableException!

I do think that log4j-user is going to recieve a lot of emails about why
config files quit working. I would grab a 1.3 and slap it in place of 1.2.8
without thinking about it if I didn't know how big the 1.3 upgrade was for
log4j.

Geir, have you thought about using commons-logging as a wrapper/hider of the
other logging solutions? That might allow you to not include log4j and
logkit jars, and give you support of theoretically many logging solutions?

ERic

-----Original Message-----
Sent: Tuesday, November 30, 2004 3:50 PM
To: Ceki Gülcü
Subject: Re: failure notice

some lists choose to moderate...

Hello Geir,
We currently don't but may switch back to moderated list. Sorry
about the hassle.

anyway, the interesting thing is the problem I have fixing Velocity
so Gump is happy ...

Niclas Hedhman informed us of this problem. There was a conscious
choice to remove the old RollingAppender and replace with something
better.

That's all well and good, but why not deprecate for a version?

Because the old RollingAppender has bugs. Consequently, we don't want
to make it available to Mrs. Piggy in the next version of log4j 1.3.

Mrs. Piggy?
Can you make o.a.l.RFA be an adapter for o.a.l.rolling.RFA?

Post by Geir Magnusson Jr
But what gump has done here is given us early warning that if one of
us doesn't do something, Velocity users [and every other log4j user
using RollingFileAppender] are *screwed* if they try to upgrade a
minor version number of log4j, to 1.3.
What I want is that existing velocity users can upgrade to log4j 1.3
w/o hassle.

Log4j 1.3 is currently in alpha. Ignore 1.3 until it goes RC. When it
goes RC, switch to 1.3. It should be trivial to do so.

It is, but requires a code change. For people with code in production,
asking to do a code change to upgrade log4j is asking a lot.

Post by Geir Magnusson Jr
But forgetting Gump, in general, what do you want me and other users
to do? have to modify our code to update to 1.3?

Wait, don't do anything for the time being. Velocity ships with a copy
log4j doesn't it?

no, we just tell people that we have a logger that writes to it.

We don't ship log4j. We support having velocity log to a whole bunch
of things, log4j being one of them (and probably the most popular...)
geir

--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport

--
Geir Magnusson Jr +1-203-665-6437
---------------------------------------------------------------------

Geir Magnusson Jr

2004-11-30 16:17:44 UTC

Post by Eric Pugh
Jar upgrades are never easy. I would venture a guess that in Log4j world,
1.3 is the equvalent of 2.0 in other projects. Especially if you count how
many 1.2.x releases there where..

So call it 2.0!

Post by Eric Pugh
The worst thing that can happen is that the o.a.l.RFA class is grabbed out
of log4j just to provide the compatiblity. I hate that when I have
hibernate.jar and commons-lang.jar that eclipse prompts me for which path to
import from for my NestableException!

Agreed.

Post by Eric Pugh
I do think that log4j-user is going to recieve a lot of emails about why
config files quit working. I would grab a 1.3 and slap it in place of 1.2.8
without thinking about it if I didn't know how big the 1.3 upgrade was for
log4j.

exactly

Post by Eric Pugh
Geir, have you thought about using commons-logging as a wrapper/hider of the
other logging solutions? That might allow you to not include log4j and
logkit jars, and give you support of theoretically many logging solutions?

LOL. Sorry, I'm not a big fan of commons-logging... I prefer the IOC
pattern. This is an adapter included w/ Velocity, not it's core
functionality.

geir

Post by Eric Pugh
ERic

-----Original Message-----
Sent: Tuesday, November 30, 2004 3:50 PM
To: Ceki Gülcü
Subject: Re: failure notice

some lists choose to moderate...

Hello Geir,
We currently don't but may switch back to moderated list. Sorry
about the hassle.

anyway, the interesting thing is the problem I have fixing Velocity
so Gump is happy ...

Niclas Hedhman informed us of this problem. There was a conscious
choice to remove the old RollingAppender and replace with something
better.

That's all well and good, but why not deprecate for a version?

Because the old RollingAppender has bugs. Consequently, we don't want
to make it available to Mrs. Piggy in the next version of log4j 1.3.

Mrs. Piggy?
Can you make o.a.l.RFA be an adapter for o.a.l.rolling.RFA?

Post by Geir Magnusson Jr
But what gump has done here is given us early warning that if one of
us doesn't do something, Velocity users [and every other log4j user
using RollingFileAppender] are *screwed* if they try to upgrade a
minor version number of log4j, to 1.3.
What I want is that existing velocity users can upgrade to log4j 1.3
w/o hassle.

Log4j 1.3 is currently in alpha. Ignore 1.3 until it goes RC. When it
goes RC, switch to 1.3. It should be trivial to do so.

It is, but requires a code change. For people with code in
production,
asking to do a code change to upgrade log4j is asking a lot.

Post by Geir Magnusson Jr
But forgetting Gump, in general, what do you want me and other users
to do? have to modify our code to update to 1.3?

Wait, don't do anything for the time being. Velocity ships with a copy
log4j doesn't it?

no, we just tell people that we have a logger that writes to it.

We don't ship log4j. We support having velocity log to a whole bunch
of things, log4j being one of them (and probably the most popular...)
geir

--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport

--
Geir Magnusson Jr +1-203-665-6437
---------------------------------------------------------------------

---------------------------------------------------------------------

--
Geir Magnusson Jr +1-203-665-6437
***@gluecode.com

Ceki Gülcü

2004-11-30 16:08:46 UTC

Post by Ceki GÃ¼lcÃ¼
Because the old RollingAppender has bugs. Consequently, we don't want to
make it available to Mrs. Piggy in the next version of log4j 1.3.

Mrs. Piggy?

Mrs. Piggy, the proverbial log4j user.

Post by Geir Magnusson Jr
Can you make o.a.l.RFA be an adapter for o.a.l.rolling.RFA?

Technically, yes. Nevertheless, adapters like this take a lot more time
than people generally think.

--
Ceki Gülcü

The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport

Eric Pugh

2004-11-30 14:03:19 UTC

I actually checked in a change to the gump build to do this.. However,
today xerces fell over, so now nobodies running at all.. When it runs
again, hopefully we'll see it work. Of course, I may not have done it
properly ;-)

Eric

-----Original Message-----
Sent: Tuesday, November 30, 2004 2:33 PM
To: Geir Magnusson Jr
Subject: Re: Fwd: failure notice

some lists choose to moderate...

Hello Geir,
We currently don't but may switch back to moderated list. Sorry about the
hassle.

anyway, the interesting thing is the problem I have fixing Velocity so
Gump is happy ...

Niclas Hedhman informed us of this problem. There was a conscious choice to
remove the old RollingAppender and replace with something better.
To help you solve this problem there several routes exists. First and more
philosophically, there is more to software development than keeping gump
happy. Having said that, you can keep gump happy by either switching to
FileAppender or keep your own version of RollingFileAppender.
Perhaps the easiest alternative is to have velocity explicitly tell gump
that velocity depends on log4j 1.2.x and not log4j head. Actually this
would be he action I would recommended.
I hope this helps,

Date: November 29, 2004 9:29:02 PM EST
Subject: failure notice
Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the

following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.
Sorry, only subscribers may post. If you are a subscriber,

please forward

address included (#5.7.2)
--- Below this line is a copy of the message.
Received: (qmail 13066 invoked by uid 99); 30 Nov 2004 02:29:02 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from chi.mobile-health-diary.com (HELO
chi.mobile-health-diary.com) (128.241.244.71)
by apache.org (qpsmtpd/0.28) with SMTP; Mon, 29 Nov 2004

18:29:02 -0800

Received: (qmail 11965 invoked from network); 30 Nov 2004 02:29:00 -0000
Received: from ool-43560634.dyn.optonline.net (HELO ?10.0.1.2?)
by b014.internal.mobile-health-diary.com with SMTP; 30 Nov 2004
02:29:00 -0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: Gump reporting
Date: Mon, 29 Nov 2004 21:28:57 -0500
X-Mailer: Apple Mail (2.619)
X-Virus-Checked: Checked
Why isn't this backwards compatible?
I'm trying to fix this, but I can't. There is no released

version of =20=

log4j that has this change, and I won't have vel based on

whatever we =20=

can build from head-du-jour.
Is there a way to make this backwards compatible? Like deprecate =20
o.a.l.RFA, release so we can switch to o.a.l.rolling.RFA?
geir

But how do you constrain the use of disk space with the FileAppender?
With the RollingFileAppender, that is a simple matter of =

configuration.

Regards,
Paulo Gaspar

Hi Niclas,
The change is not not a backward compatible. My suggestion

would be =20=

use a simple FileAppender instead of RollingFileAppender.

Hi,
http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-=20
velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html
Jakarta Velocity is somehow using the RollingFileAppender in

code, =20=

and I
wonder if you guys have moved it from
org.apache.log4j.RollingFileAppender
to
org.apache.log4j.rolling.RollingFileAppender
and whether this constitutes a compatible change or not, as

I think =20=

if this is
the case, it will also break a lot of configuration files out there.
Thanks for any feedback.
Cheers
Niclas

--
Ceki Gülcü
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------

Stefano Mazzocchi

2004-11-30 17:36:07 UTC

Post by Ceki GÃ¼lcÃ¼
To help you solve this problem there several routes exists. First and
more philosophically, there is more to software development than keeping
gump happy.

Sure thing.

But also, to keep the philosophical tune, when the wise points at the
stars, the fool looks at the finger.

--
Stefano.

Stefan Bodewig

2004-12-01 08:02:35 UTC