You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Ceki Gülcü <ce...@qos.ch> on 2004/11/26 14:21:45 UTC
Re: Gump reporting
Hi Niclas,
The change is not not a backward compatible. My suggestion would be use a
simple FileAppender instead of RollingFileAppender.
At 02:13 PM 11/26/2004, Niclas Hedhman wrote:
>Hi,
>
>http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html
>
>Jakarta Velocity is somehow using the RollingFileAppender in code, 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 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
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 1, 2004, at 6:55 AM, Henning P. Schmiedehausen wrote:
> Geir Magnusson Jr <ge...@4quarters.com> writes:
>
>> On Nov 30, 2004, at 8:23 AM, Henning P. Schmiedehausen wrote:
>
> [...]
>>> I tried to get exactly that point across (Project X does rely on
>>> Version n of Project Y, not the HEAD) but failed. Maybe you are more
>>> successful...
>
>> This has been the basic issue since Gump was started. It's good at
>> showing when someone breaks an API contract, such as this case. What
>> it can't seem to handle is the legitimate case of API breakage in
>> major
>> revisioning.
>
> Yep.
>
>> If log4j was doing this going from 1.2.9 to 2.0, then I'd probably
>> have
>> to wave off any complaints. But 1.2.9 to 1.3? sorry - I can't see
>> why
>> they are doing this, as they have historically been so good about
>> smooth, manageable changes in the log4j API.
>
>> This further supports my belief that you always want to minimize
>> dependencies.
>
> This is why I tried to lobby for commons-logging here a while
> ago. Using commons-logging, this change would have been invisible
> because c-l separates the library from the logging API.
Don't even start.
>
>> My strategy here is to try and get them to at least give us a
>> deprecated o.a.l.RFA for 1.3.0 so we can switch to a released version,
>> and then immediately we switch to using the RFA in the rolling
>> package.
>
> +1
>
>> The other option is to play classpath wack-a-mole and just no have any
>> hard imports, do everything via classloader discovery, and wait until
>> this is over...
>
> /me barfs. Please not. In Turbine, we used commons-logging with great
> success. All the log4j stuff disappeared into the log4j.properties
> file. Ok, you would have to adjust this.
LOL. I was mostly kidding. I've been discussing this both privately
w/ Ceki and on the gump list, and I just don't grok Ceki's point of
view. Up until now, he's been so accommodating to the log4j user
community for backwards compatibility.
Anyway, there's no clear way out of this, other than to offer both
versions (a 1.2.x compatible version, and a 1.3 compatible version) and
have people build what they need. I don't really like it, though...
<sigh>
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
> hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> What is more important to you...
> [ ] Product Security
> or [ ] Quality of Sales and Marketing Support
> -- actual question from a Microsoft customer survey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Geir Magnusson Jr <ge...@4quarters.com> writes:
>On Nov 30, 2004, at 8:23 AM, Henning P. Schmiedehausen wrote:
[...]
>> I tried to get exactly that point across (Project X does rely on
>> Version n of Project Y, not the HEAD) but failed. Maybe you are more
>> successful...
>This has been the basic issue since Gump was started. It's good at
>showing when someone breaks an API contract, such as this case. What
>it can't seem to handle is the legitimate case of API breakage in major
>revisioning.
Yep.
>If log4j was doing this going from 1.2.9 to 2.0, then I'd probably have
>to wave off any complaints. But 1.2.9 to 1.3? sorry - I can't see why
>they are doing this, as they have historically been so good about
>smooth, manageable changes in the log4j API.
>This further supports my belief that you always want to minimize
>dependencies.
This is why I tried to lobby for commons-logging here a while
ago. Using commons-logging, this change would have been invisible
because c-l separates the library from the logging API.
>My strategy here is to try and get them to at least give us a
>deprecated o.a.l.RFA for 1.3.0 so we can switch to a released version,
>and then immediately we switch to using the RFA in the rolling package.
+1
>The other option is to play classpath wack-a-mole and just no have any
>hard imports, do everything via classloader discovery, and wait until
>this is over...
/me barfs. Please not. In Turbine, we used commons-logging with great
success. All the log4j stuff disappeared into the log4j.properties
file. Ok, you would have to adjust this.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Nov 30, 2004, at 8:23 AM, Henning P. Schmiedehausen wrote:
> Geir Magnusson Jr <ge...@4quarters.com> writes:
>
>> Why isn't this backwards compatible?
>
>> I'm trying to fix this, but I can't. There is no released version of
>> log4j that has this change, and I won't have vel based on whatever we
>> can build from head-du-jour.
>
> You should've sit next to Stefano for a while @ ApacheCon.
>
> My personal summary was: "Gump is not a build reporting tool. It is a
> social experiment..." =%-)
>
> I tried to get exactly that point across (Project X does rely on
> Version n of Project Y, not the HEAD) but failed. Maybe you are more
> successful...
This has been the basic issue since Gump was started. It's good at
showing when someone breaks an API contract, such as this case. What
it can't seem to handle is the legitimate case of API breakage in major
revisioning.
If log4j was doing this going from 1.2.9 to 2.0, then I'd probably have
to wave off any complaints. But 1.2.9 to 1.3? sorry - I can't see why
they are doing this, as they have historically been so good about
smooth, manageable changes in the log4j API.
This further supports my belief that you always want to minimize
dependencies.
My strategy here is to try and get them to at least give us a
deprecated o.a.l.RFA for 1.3.0 so we can switch to a released version,
and then immediately we switch to using the RFA in the rolling package.
The other option is to play classpath wack-a-mole and just no have any
hard imports, do everything via classloader discovery, and wait until
this is over...
geir
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
> hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> What is more important to you...
> [ ] Product Security
> or [ ] Quality of Sales and Marketing Support
> -- actual question from a Microsoft customer survey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Geir Magnusson Jr <ge...@4quarters.com> writes:
>Why isn't this backwards compatible?
>I'm trying to fix this, but I can't. There is no released version of
>log4j that has this change, and I won't have vel based on whatever we
>can build from head-du-jour.
You should've sit next to Stefano for a while @ ApacheCon.
My personal summary was: "Gump is not a build reporting tool. It is a
social experiment..." =%-)
I tried to get exactly that point across (Project X does rely on
Version n of Project Y, not the HEAD) but failed. Maybe you are more
successful...
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
Why isn't this backwards compatible?
I'm trying to fix this, but I can't. There is no released version of
log4j that has this change, and I won't have vel based on whatever we
can build from head-du-jour.
Is there a way to make this backwards compatible? Like deprecate
o.a.l.RFA, release so we can switch to o.a.l.rolling.RFA?
geir
On Nov 28, 2004, at 2:38 PM, Paulo Gaspar wrote:
> 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
>
> Ceki Gülcü wrote:
>
>>
>> Hi Niclas,
>>
>> The change is not not a backward compatible. My suggestion would be
>> use a simple FileAppender instead of RollingFileAppender.
>>
>> At 02:13 PM 11/26/2004, Niclas Hedhman wrote:
>>
>>> Hi,
>>>
>>> http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-
>>> velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html
>>>
>>> Jakarta Velocity is somehow using the RollingFileAppender in code,
>>> 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
>>> if this is
>>> the case, it will also break a lot of configuration files out there.
>>>
>>> Thanks for any feedback.
>>>
>>> Cheers
>>> Niclas
>>>
>>> --
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
Why isn't this backwards compatible?
I'm trying to fix this, but I can't. There is no released version of
log4j that has this change, and I won't have vel based on whatever we
can build from head-du-jour.
Is there a way to make this backwards compatible? Like deprecate
o.a.l.RFA, release so we can switch to o.a.l.rolling.RFA?
geir
On Nov 28, 2004, at 2:38 PM, Paulo Gaspar wrote:
> 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
>
> Ceki Gülcü wrote:
>
>>
>> Hi Niclas,
>>
>> The change is not not a backward compatible. My suggestion would be
>> use a simple FileAppender instead of RollingFileAppender.
>>
>> At 02:13 PM 11/26/2004, Niclas Hedhman wrote:
>>
>>> Hi,
>>>
>>> http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-
>>> velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html
>>>
>>> Jakarta Velocity is somehow using the RollingFileAppender in code,
>>> 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
>>> if this is
>>> the case, it will also break a lot of configuration files out there.
>>>
>>> Thanks for any feedback.
>>>
>>> Cheers
>>> Niclas
>>>
>>> --
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump reporting
Posted by Paulo Gaspar <li...@kebom.net>.
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
Ceki Gülcü wrote:
>
> Hi Niclas,
>
> The change is not not a backward compatible. My suggestion would be
> use a simple FileAppender instead of RollingFileAppender.
>
> At 02:13 PM 11/26/2004, Niclas Hedhman wrote:
>
>> Hi,
>>
>> http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html
>>
>>
>> Jakarta Velocity is somehow using the RollingFileAppender in code, 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
>> if this is
>> the case, it will also break a lot of configuration files out there.
>>
>> Thanks for any feedback.
>>
>> Cheers
>> Niclas
>>
>> --
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by Paulo Gaspar <de...@kebom.net>.
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
Ceki Gülcü wrote:
>
> Hi Niclas,
>
> The change is not not a backward compatible. My suggestion would be
> use a simple FileAppender instead of RollingFileAppender.
>
> At 02:13 PM 11/26/2004, Niclas Hedhman wrote:
>
>> Hi,
>>
>> http://brutus.apache.org/gump/public/jakarta-velocity/jakarta-velocity/gump_work/build_jakarta-velocity_jakarta-velocity.html
>>
>>
>> Jakarta Velocity is somehow using the RollingFileAppender in code, 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
>> if this is
>> the case, it will also break a lot of configuration files out there.
>>
>> Thanks for any feedback.
>>
>> Cheers
>> Niclas
>>
>> --
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Gump reporting
Posted by Ceki Gülcü <ce...@qos.ch>.
At 02:54 PM 11/26/2004, you wrote:
>On Friday 26 November 2004 21:21, Ceki Gülcü wrote:
>
>Ceki,
>
> > The change is not not a backward compatible. My suggestion would be use a
> > simple FileAppender instead of RollingFileAppender.
>
>One too many "not" ?
My bad.
>Assuming that is the case, are we talking about a Log4J 2.0 in the making, or
>is 1.3 just saying "you need to change your log4j.xml" to all the users out
>there?
>(Now I asking as a user, and not a developer.)
Yep, Mrs. Piggy User will need to change her config files. However, in
exchange she'll get something that works well, with real added value.
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Gump reporting
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 26 November 2004 21:21, Ceki Gülcü wrote:
Ceki,
> The change is not not a backward compatible. My suggestion would be use a
> simple FileAppender instead of RollingFileAppender.
One too many "not" ?
Assuming that is the case, are we talking about a Log4J 2.0 in the making, or
is 1.3 just saying "you need to change your log4j.xml" to all the users out
there?
(Now I asking as a user, and not a developer.)
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org