Discussion:
failure notice
(too old to reply)
Ceki Gülcü
2004-11-30 13:32:42 UTC
Permalink
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
Niclas Hedhman
2004-11-30 13:49:54 UTC
Permalink
Post by Ceki Gülcü
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
Permalink
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
Permalink
Post by Ceki Gülcü
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.
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
--
Geir Magnusson Jr +1-203-665-6437
***@gluecode.com
Ceki Gülcü
2004-11-30 14:32:06 UTC
Permalink
Post by Geir Magnusson Jr
Post by Ceki Gülcü
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?
Post by Geir Magnusson Jr
geir
--
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
Permalink
Post by Ceki Gülcü
Post by Geir Magnusson Jr
Post by Ceki Gülcü
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 Ceki Gülcü
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 Ceki Gülcü
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
Post by Ceki Gülcü
Post by Geir Magnusson Jr
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
Permalink
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
Post by Ceki Gülcü
Post by Geir Magnusson Jr
Post by Ceki Gülcü
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 Ceki Gülcü
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 Ceki Gülcü
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
Post by Ceki Gülcü
Post by Geir Magnusson Jr
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
Permalink
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
Post by Ceki Gülcü
Post by Geir Magnusson Jr
Post by Ceki Gülcü
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 Ceki Gülcü
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 Ceki Gülcü
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
Post by Ceki Gülcü
Post by Geir Magnusson Jr
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
Permalink
Post by Geir Magnusson Jr
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
Permalink
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
Permalink
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
Permalink
First and more philosophically, there is more to software
development than keeping gump happy.
Absolutely. But then again, Gump is probably happy right now since it
has told the log4j project that its change will require a code change
in velocity if velocity ever wants to upgrade to log4j 1.3.

If we are able to build velocity in Gump it should make the velocity
developers happy. If all projects that depend on log4j can build
against log4j's CVS HEAD, this should make log4j's developers and
users happy. If they can't, well, this doesn't make Gump unhappy.
Perhaps the easiest alternative is to have velocity explicitly tell
gump that velocity depends on log4j 1.2.x and not log4j
head.
I think this has been done, so we are working around the change
already (once we get to building anything at all again).

Less philosophical, I'd suggest (and I think this is in line with
Geir's suggestions as well), that you add a rolling package to the 1.2
branch and carve a 1.2.10 release with it. The easiest and ugliest
hack would simply copy the existing RollingFileAppender and change the
package name.

Cheers

Stefan

Continue reading on narkive:
Loading...