You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Curt Arnold <ca...@apache.org> on 2009/05/12 06:45:26 UTC
log4j 1.2.16 RC1: last call for bugs
If you have a bug that you'd really like to see integrated and there
is an available patch or the solution isn't a totally rearch of log4j,
please speak up. I hope to cut a release candidate this week. Will
try to make a sweep through the open bugs for ones that can be
resolved, but might miss someone's favorite.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Jess Holle <je...@ptc.com>.
Curt Arnold wrote:
> On May 13, 2009, at 6:19 AM, Jess Holle wrote:
>> Curt Arnold wrote:
>>> Sorry hadn't followed that one. It seems like a good replacement
>>> for some not ready for primetime code that has been in log4j for a
>>> while. However, since it is all new code and not any modifications
>>> to existing log4j classes, it would make a good candidate for a
>>> log4j companion. In a perfect world, they should be able to rev
>>> faster than the main log4j release.
>>>
>>> I'll see about packing that up in the sandbox as a companion and see
>>> if we can get any feedback on it.
>> Agreed. I'd long since given up on this being fixed and written my
>> own JMX monitoring classes for log4j.
>>
>> Given use cases like usage of log4j on the client, I'd rather not
>> shove new JMX monitoring classes into the main log4j jar. Instead
>> providing these in an optional companion jar makes much more sense.
>>
>> [For that matter given the state of the JMX classes that are present,
>> it would be good to remove those...]
>>
>> --
>> Jess Holle
Understood -- though a log4j-core.jar might be in order if there are
other packages in a similar boat.
Of course I could just make a log4j-core.jar for my own usages as well.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Jacob Kjome <ho...@visi.com>.
On 5/13/2009 9:26 PM, Paul Smith wrote:
>>
>> Can't yank it from log4j.jar without potentially breaking some app
>> that actually uses it, but could mark it as deprecated and suggest
>> checking the jmx companion.
>
> the alternative is to start yanking things out of log4j into a 'legacy'
> jar. People that wish to upgrade log4j jars, need perhaps drop in this
> extra one for compatibility.
>
> newer versions of whatever can then go into other companion libraries.
>
> Paul
I concur. Don't forget to extract LogFactor5 and Chainsaw1 into lgo4j-legacy.jar.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Paul Smith <ps...@aconex.com>.
>
> Can't yank it from log4j.jar without potentially breaking some app
> that actually uses it, but could mark it as deprecated and suggest
> checking the jmx companion.
the alternative is to start yanking things out of log4j into a
'legacy' jar. People that wish to upgrade log4j jars, need perhaps
drop in this extra one for compatibility.
newer versions of whatever can then go into other companion libraries.
Paul
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Curt Arnold <ca...@apache.org>.
On May 13, 2009, at 6:19 AM, Jess Holle wrote:
> Curt Arnold wrote:
>>
>> Sorry hadn't followed that one. It seems like a good replacement
>> for some not ready for primetime code that has been in log4j for a
>> while. However, since it is all new code and not any modifications
>> to existing log4j classes, it would make a good candidate for a
>> log4j companion. In a perfect world, they should be able to rev
>> faster than the main log4j release.
>>
>> I'll see about packing that up in the sandbox as a companion and
>> see if we can get any feedback on it.
> Agreed. I'd long since given up on this being fixed and written my
> own JMX monitoring classes for log4j.
>
> Given use cases like usage of log4j on the client, I'd rather not
> shove new JMX monitoring classes into the main log4j jar. Instead
> providing these in an optional companion jar makes much more sense.
>
> [For that matter given the state of the JMX classes that are
> present, it would be good to remove those...]
>
> --
> Jess Holle
>
Can't yank it from log4j.jar without potentially breaking some app
that actually uses it, but could mark it as deprecated and suggest
checking the jmx companion.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Jess Holle <je...@ptc.com>.
Curt Arnold wrote:
> Sorry hadn't followed that one. It seems like a good replacement for
> some not ready for primetime code that has been in log4j for a while.
> However, since it is all new code and not any modifications to
> existing log4j classes, it would make a good candidate for a log4j
> companion. In a perfect world, they should be able to rev faster than
> the main log4j release.
>
> I'll see about packing that up in the sandbox as a companion and see
> if we can get any feedback on it.
Agreed. I'd long since given up on this being fixed and written my own
JMX monitoring classes for log4j.
Given use cases like usage of log4j on the client, I'd rather not shove
new JMX monitoring classes into the main log4j jar. Instead providing
these in an optional companion jar makes much more sense.
[For that matter given the state of the JMX classes that /are/ present,
it would be good to remove those...]
--
Jess Holle
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Scott Deboy <sc...@gmail.com>.
My changes are in (Chainsaw find next/clear find next context menu items and
enhancements to vfs/logfilepatternreceiver).
I should have added the find next/clear find next to menus but I've ran out
of time for now...
Scott
On Tue, May 12, 2009 at 10:26 PM, Scott Deboy <sc...@gmail.com> wrote:
> I have a couple of additions to make to
> Chainsaw/LogFilePatternReceiver..should be done tonight hopefully..
>
>
> On Tue, May 12, 2009 at 9:59 PM, Curt Arnold <ca...@apache.org> wrote:
>
>>
>> On May 12, 2009, at 5:36 AM, Stefan Fleiter wrote:
>>
>> Sorry, I have to correct myself:
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=44308
>>>> This bug contains a patch for JMX Management of Log4j Appenders and
>>>> their log levels.
>>>>
>>>
>>> The levels of *loggers* can be configured.
>>>
>>>
>>
>> Sorry hadn't followed that one. It seems like a good replacement for some
>> not ready for primetime code that has been in log4j for a while. However,
>> since it is all new code and not any modifications to existing log4j
>> classes, it would make a good candidate for a log4j companion. In a perfect
>> world, they should be able to rev faster than the main log4j release.
>>
>> I'll see about packing that up in the sandbox as a companion and see if we
>> can get any feedback on it.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Scott Deboy <sc...@gmail.com>.
I have a couple of additions to make to
Chainsaw/LogFilePatternReceiver..should be done tonight hopefully..
On Tue, May 12, 2009 at 9:59 PM, Curt Arnold <ca...@apache.org> wrote:
>
> On May 12, 2009, at 5:36 AM, Stefan Fleiter wrote:
>
> Sorry, I have to correct myself:
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=44308
>>> This bug contains a patch for JMX Management of Log4j Appenders and
>>> their log levels.
>>>
>>
>> The levels of *loggers* can be configured.
>>
>>
>
> Sorry hadn't followed that one. It seems like a good replacement for some
> not ready for primetime code that has been in log4j for a while. However,
> since it is all new code and not any modifications to existing log4j
> classes, it would make a good candidate for a log4j companion. In a perfect
> world, they should be able to rev faster than the main log4j release.
>
> I'll see about packing that up in the sandbox as a companion and see if we
> can get any feedback on it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Curt Arnold <ca...@apache.org>.
On May 12, 2009, at 5:36 AM, Stefan Fleiter wrote:
> Sorry, I have to correct myself:
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=44308
>> This bug contains a patch for JMX Management of Log4j Appenders and
>> their log levels.
>
> The levels of *loggers* can be configured.
>
Sorry hadn't followed that one. It seems like a good replacement for
some not ready for primetime code that has been in log4j for a while.
However, since it is all new code and not any modifications to
existing log4j classes, it would make a good candidate for a log4j
companion. In a perfect world, they should be able to rev faster than
the main log4j release.
I'll see about packing that up in the sandbox as a companion and see
if we can get any feedback on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Stefan Fleiter <st...@web.de>.
Sorry, I have to correct myself:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=44308
> This bug contains a patch for JMX Management of Log4j Appenders and
> their log levels.
The levels of *loggers* can be configured.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.2.16 RC1: last call for bugs
Posted by Stefan Fleiter <st...@web.de>.
Curt Arnold wrote:
> If you have a bug that you'd really like to see integrated and there is
> an available patch or the solution isn't a totally rearch of log4j,
> please speak up.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44308
This bug contains a patch for JMX Management of Log4j Appenders and
their log levels.
Log4j comes with HierarchyDynamicMBean for managing Log4j by means of
JMX, but that class has the following restrictions:
- It can not be registered more than once at the same MBean server, this
is a critical restriction in J2EE Environments.
- Only loggers specified in the Log4j configuration file can be
configured.
- The code is overly complex.
The patch in Bug 44308 contains simple management calls with optional
stepwise rollback which can come handy when modifying log levels in
a production environment.
> I hope to cut a release candidate this week. Will try
> to make a sweep through the open bugs for ones that can be resolved, but
> might miss someone's favorite.
Wow, thanks for doing all the work!
Greetings,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org