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 Ralph Goers <ra...@dslextreme.com> on 2014/07/11 08:50:01 UTC
Next release
I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
I know I haven't had time to spend on this project lately, but I never
finished off LOG4J2-609 <https://issues.apache.org/jira/browse/LOG4J2-609>.
If you're itching to release this weekend, then I won't be able to get this
done. The solution I'm presenting is a little bit invasive in the "API",
but I think the current solution has some real problems. The details are in
the JIRA. I only bring it up in case you think this area of the API should
not be allowed to change after 2.0. It is kind of off in a corner where
most people won't go, so maybe it will be acceptable to fix for a 2.1
release. Where it stands right now, I don't have the tests working, which I
now thing is showing a problem with something in my solution.
What are your thoughts?
Other than that, I would really like to see 2.0 released.
On Fri, Jul 11, 2014 at 8:47 PM, Remko Popma <re...@gmail.com> wrote:
>
>
> On Friday, July 11, 2014, Remko Popma <re...@gmail.com> wrote:
>
>> No objection at all!
>>
>> I would like to add the tool to generate Custom/Extended Loggers, and do
>> a doc fix for LOG4J2-631.
>
> Done with these changes.
>
>>
>> Also, the site now has an empty section "Custom Plugins" under manual >
>> Extending Log4j. Shall we remove that before the release?
>
> I haven't had time to do this. I may not have time today either. Perhaps
> not that urgent anyway...
>
> One more thing (gentle reminder): let's not forget to change to the new
> logo. :-)
>
>
>>
>> Sent from my iPhone
>>
>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>> >
>> > I would like to do the release for Log4j 2.0 this weekend. Are there
>> any objections?
>> >
>> > Ralph
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>
--
Bruce Brouwer
about.me/bruce.brouwer
[image: Bruce Brouwer on about.me]
<http://about.me/bruce.brouwer>
Re: Next release
Posted by Remko Popma <re...@gmail.com>.
On Friday, July 11, 2014, Remko Popma <re...@gmail.com> wrote:
> No objection at all!
>
> I would like to add the tool to generate Custom/Extended Loggers, and do a
> doc fix for LOG4J2-631.
Done with these changes.
>
> Also, the site now has an empty section "Custom Plugins" under manual >
> Extending Log4j. Shall we remove that before the release?
I haven't had time to do this. I may not have time today either. Perhaps
not that urgent anyway...
One more thing (gentle reminder): let's not forget to change to the new
logo. :-)
>
> Sent from my iPhone
>
> > On 2014/07/11, at 15:50, Ralph Goers <ralph.goers@dslextreme.com
> <javascript:;>> wrote:
> >
> > I would like to do the release for Log4j 2.0 this weekend. Are there any
> objections?
> >
> > Ralph
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> <javascript:;>
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> <javascript:;>
> >
>
Re: Next release
Posted by Remko Popma <re...@gmail.com>.
On Sunday, July 13, 2014, Bruno Mahé <bm...@tango.me> wrote:
> Hi,
>
> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have
> been very impressed.
> We are in the process of migrating our services to Apache Log 2.0rc2 so
> they can be ready for roll out when 2.0 comes out.
>
> The only issue we had so far was about configuring async logger for all
> loggers. Having to pass system properties to Apache Tomcat in order to
> activate and configure async loggers is not convenient.
>
This is on the todo list. Keep an eye on
https://issues.apache.org/jira/browse/LOG4J2-321
>
> There is also a more detailed email/blog post with some numbers we
> collected being worked on.
>
Looking forward to the blog!
>
>
> Thanks,
> Bruno
>
> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>
> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>
>
> On 11 July 2014 03:58, Remko Popma <remko.popma@gmail.com
> <javascript:_e(%7B%7D,'cvml','remko.popma@gmail.com');>> wrote:
>
>> No objection at all!
>>
>> I would like to add the tool to generate Custom/Extended Loggers, and do
>> a doc fix for LOG4J2-631.
>>
>> Also, the site now has an empty section "Custom Plugins" under manual >
>> Extending Log4j. Shall we remove that before the release?
>>
>> Sent from my iPhone
>>
>> > On 2014/07/11, at 15:50, Ralph Goers <ralph.goers@dslextreme.com
>> <javascript:_e(%7B%7D,'cvml','ralph.goers@dslextreme.com');>> wrote:
>> >
>> > I would like to do the release for Log4j 2.0 this weekend. Are there
>> any objections?
>> >
>> > Ralph
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> <javascript:_e(%7B%7D,'cvml','log4j-dev-unsubscribe@logging.apache.org');>
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> <javascript:_e(%7B%7D,'cvml','log4j-dev-help@logging.apache.org');>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> <javascript:_e(%7B%7D,'cvml','log4j-dev-unsubscribe@logging.apache.org');>
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> <javascript:_e(%7B%7D,'cvml','log4j-dev-help@logging.apache.org');>
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com
> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
>
>
>
Re: Next release
Posted by Ralph Goers <ra...@dslextreme.com>.
Bruce,
My opinion is that in production in a web container the StatusLogger should ALWAYS be routed to stdout. The volume of output should normally be small if you are logging at Error. Second, in the ideal case you should only have a single log level, regardless of how many web applications there are. To me, anything else is just confusing. What you are really trying to do with the StatusLogger is be informed about any errors that may happen in the logging system. If you are only logging to a console and everything is uniformly set to Error then I don’t ever see a problem arising.
The trouble comes into play when you try to use StatusLogger for something it really wasn’t intended for. For example, I would only recommend StatusLogger be routed to a file if Debug is enabled and that should only ever happen outside of a production environment.
I guess what I am saying is that I don’t think we should go overboard trying to make StatusLogger into something more than what it is - a way to debug errors in the logging configuration or issues with Appenders.
I am fine with adding javadoc and/or annotations to StatusLogger and its friends to clearly mark them as for internal use, but I don’t think they are critical enough to hold up on releasing 2.0.
Ralph
On Jul 13, 2014, at 11:44 AM, Bruce Brouwer <br...@gmail.com> wrote:
> Rats! It's not so simple as what I wrote.
>
> The crux of the problem is that the various Configuration classes need to control what shows up on the console from the StatusLogger. The way they've been doing that is finding the existing listener and reconfiguring it. There are some problems that will arise as you add new Configuration instances (e.g. multiple web apps sharing the same classloader) where these configurations build up over time. Additionally, nothing ever cleans them up as a configuration is reloaded so you might start logging at debug level to the console even though there is no configuration telling it to log at debug level. Also, depending on the order of reconfigurations, you might only be logging fatals to the console even though the current configuration is set to debug level.
>
> It seemed more appropriate to me to introduce a new concept, the StatusFilter. Since these are really trying to filter what shows up on the console, it seemed more appropriate than a listener. My solution to these problems is what brought about my API changes to StatusLogger, which is somewhat significant. But to solve these problems, I think my changes are necessary.
>
> If we consider these changes important enough, I'd like to get them in before 2.0, even though some may consider StatusLogger to not be "part of the API" even though it is in log4j-api.
>
> I checked in the first set of changes to the LOG4J2-609 branch.
>
> If we don't make these changes for 2.0, I really want to put JavaDoc on the stuff in ...log4j.status that clearly states this is for internal use only and may change in a breaking way in the future.
>
>
> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com> wrote:
>
> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
> Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0 release. If you like it, we can put just that in trunk and release.
>
> Sounds good.
>
> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
> Hi,
>
> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed.
> We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out.
>
> The only issue we had so far was about configuring async logger for all loggers. Having to pass system properties to Apache Tomcat in order to activate and configure async loggers is not convenient.
>
> There is also a more detailed email/blog post with some numbers we collected being worked on.
>
> Thanks,
> Bruno
>
> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>
>>
>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>> No objection at all!
>>
>> I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631.
>>
>> Also, the site now has an empty section "Custom Plugins" under manual > Extending Log4j. Shall we remove that before the release?
>>
>> Sent from my iPhone
>>
>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
>> >
>> > I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>> >
>> > Ralph
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
>
>
Re: Next release
Posted by Ralph Goers <ra...@dslextreme.com>.
Also, StatusLogger is final. Anyone who tries to implement a Logger based on that is going to have a hard time. StatusLogger is also intentionally primitive - you can’t do much filtering or routing to appenders, etc - so anyone who tries to use it for something is probably going to wonder why it isn’t working as they expect. Since the only documentation on it tells you have to get output from Log4j components I think the risk that someone is going to get confused is very low.
Ralph
On Jul 13, 2014, at 1:08 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> Gary, the 2.0 release vote is already in progress. I don’t see adding an annotation or comment marking something as for internal use as a reason to hold up the release.
>
> No to renaming StatusLogger. It’s name is perfectly clear to me.
>
> Ralph
>
> On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> I am hoping this will get cleaned up for the 2.0 release, especially if this affects the log4j-api module. As soon as we publish 2.0, folks will have a green light to implement their own loggers and solution and get hard-wired to the API. As a user, I would imagine that anything in log4j-api would be set in stone...
>>
>> While we are here: I always found the class name StatusLogger confusing (as is the package), for me InternalLogger (or PrivateLogger), would be clearer.
>>
>> Gary
>>
>>
>> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>> I suggest making an annotation or something to use for all the internal-use classes that are in log4j-api. It also helps to make internal use APIs all in separate packages from public APIs. That way you can make it extra obvious that if the internal API changes, too bad.
>>
>>
>> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>> Rats! It's not so simple as what I wrote.
>>
>> The crux of the problem is that the various Configuration classes need to control what shows up on the console from the StatusLogger. The way they've been doing that is finding the existing listener and reconfiguring it. There are some problems that will arise as you add new Configuration instances (e.g. multiple web apps sharing the same classloader) where these configurations build up over time. Additionally, nothing ever cleans them up as a configuration is reloaded so you might start logging at debug level to the console even though there is no configuration telling it to log at debug level. Also, depending on the order of reconfigurations, you might only be logging fatals to the console even though the current configuration is set to debug level.
>>
>> It seemed more appropriate to me to introduce a new concept, the StatusFilter. Since these are really trying to filter what shows up on the console, it seemed more appropriate than a listener. My solution to these problems is what brought about my API changes to StatusLogger, which is somewhat significant. But to solve these problems, I think my changes are necessary.
>>
>> If we consider these changes important enough, I'd like to get them in before 2.0, even though some may consider StatusLogger to not be "part of the API" even though it is in log4j-api.
>>
>> I checked in the first set of changes to the LOG4J2-609 branch.
>>
>> If we don't make these changes for 2.0, I really want to put JavaDoc on the stuff in ...log4j.status that clearly states this is for internal use only and may change in a breaking way in the future.
>>
>>
>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com> wrote:
>>
>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
>> Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0 release. If you like it, we can put just that in trunk and release.
>>
>> Sounds good.
>>
>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>> Hi,
>>
>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed.
>> We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out.
>>
>> The only issue we had so far was about configuring async logger for all loggers. Having to pass system properties to Apache Tomcat in order to activate and configure async loggers is not convenient.
>>
>> There is also a more detailed email/blog post with some numbers we collected being worked on.
>>
>> Thanks,
>> Bruno
>>
>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>
>>>
>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>> No objection at all!
>>>
>>> I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631.
>>>
>>> Also, the site now has an empty section "Custom Plugins" under manual > Extending Log4j. Shall we remove that before the release?
>>>
>>> Sent from my iPhone
>>>
>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
>>> >
>>> > I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>>> >
>>> > Ralph
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>> --
>>
>>
>> Bruce Brouwer
>> about.me/bruce.brouwer
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
Should double check better. Should not be a real performance issue
On Jul 13, 2014 7:35 PM, "Remko Popma" <re...@gmail.com> wrote:
> I haven't studied StatusLogger in that much depth, but what you're saying
> sounds good. I agree with Ralph that this is for diagnostics and it's
> better to keep this simple.
>
> Sent from my iPhone
>
> On 2014/07/14, at 8:19, Bruce Brouwer <br...@gmail.com> wrote:
>
> I'm all for making this more like a simple on/off switch. But the way
> things are setup right now, once you turn on the console logging, it can
> never be turned off. That is because once it is registered, nothing ever
> removes it.
>
> Are we ok with that?
>
> If we are, then I would like to remove all the level checking that is done
> in StatusLogger regarding these listeners and always have logs sent to the
> listeners. Let the listeners decide if they want to log something. Like was
> said, there are so few events it should be a performance issue.
>
>
> On Sun, Jul 13, 2014 at 4:39 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> I agree with Ralph on all counts regarding StatusLogger. Really, anything
>> that wants to store the StatusLogger output elsewhere is probably using
>> standard out redirection.
>>
>>
>> On 13 July 2014 15:34, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>> Also, I am against renaming StatusLogger as it will result in
>>> modifications to hundreds of files.
>>>
>>> Ralph
>>>
>>> On Jul 13, 2014, at 1:08 PM, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>> Gary, the 2.0 release vote is already in progress. I don’t see adding
>>> an annotation or comment marking something as for internal use as a reason
>>> to hold up the release.
>>>
>>> No to renaming StatusLogger. It’s name is perfectly clear to me.
>>>
>>> Ralph
>>>
>>> On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> I am hoping this will get cleaned up for the 2.0 release, especially if
>>> this affects the log4j-api module. As soon as we publish 2.0, folks will
>>> have a green light to implement their own loggers and solution and get
>>> hard-wired to the API. As a user, I would imagine that anything in
>>> log4j-api would be set in stone...
>>>
>>> While we are here: I always found the class name StatusLogger confusing
>>> (as is the package), for me InternalLogger (or PrivateLogger), would be
>>> clearer.
>>>
>>> Gary
>>>
>>>
>>> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> I suggest making an annotation or something to use for all the
>>>> internal-use classes that are in log4j-api. It also helps to make internal
>>>> use APIs all in separate packages from public APIs. That way you can make
>>>> it extra obvious that if the internal API changes, too bad.
>>>>
>>>>
>>>> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>>>>
>>>>> Rats! It's not so simple as what I wrote.
>>>>>
>>>>> The crux of the problem is that the various Configuration classes need
>>>>> to control what shows up on the console from the StatusLogger. The way
>>>>> they've been doing that is finding the existing listener and reconfiguring
>>>>> it. There are some problems that will arise as you add new Configuration
>>>>> instances (e.g. multiple web apps sharing the same classloader) where these
>>>>> configurations build up over time. Additionally, nothing ever cleans them
>>>>> up as a configuration is reloaded so you might start logging at debug level
>>>>> to the console even though there is no configuration telling it to log at
>>>>> debug level. Also, depending on the order of reconfigurations, you might
>>>>> only be logging fatals to the console even though the current configuration
>>>>> is set to debug level.
>>>>>
>>>>> It seemed more appropriate to me to introduce a new concept, the
>>>>> StatusFilter. Since these are really trying to filter what shows up on the
>>>>> console, it seemed more appropriate than a listener. My solution to these
>>>>> problems is what brought about my API changes to StatusLogger, which is
>>>>> somewhat significant. But to solve these problems, I think my changes are
>>>>> necessary.
>>>>>
>>>>> If we consider these changes important enough, I'd like to get them in
>>>>> before 2.0, even though some may consider StatusLogger to not be "part of
>>>>> the API" even though it is in log4j-api.
>>>>>
>>>>> I checked in the first set of changes to the LOG4J2-609 branch.
>>>>>
>>>>> If we don't make these changes for 2.0, I really want to put JavaDoc
>>>>> on the stuff in ...log4j.status that clearly states this is for internal
>>>>> use only and may change in a breaking way in the future.
>>>>>
>>>>>
>>>>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Here is what I am thinking. I will make the branch tomorrow and put
>>>>>>> just the minimal changes in place with the modified StatusLogger api. This
>>>>>>> way when I fix things completely we won't have a breaking api change after
>>>>>>> 2.0 release. If you like it, we can put just that in trunk and release.
>>>>>>>
>>>>>> Sounds good.
>>>>>>
>>>>>>
>>>>>>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks
>>>>>>>> and have been very impressed.
>>>>>>>> We are in the process of migrating our services to Apache Log
>>>>>>>> 2.0rc2 so they can be ready for roll out when 2.0 comes out.
>>>>>>>>
>>>>>>>> The only issue we had so far was about configuring async logger for
>>>>>>>> all loggers. Having to pass system properties to Apache Tomcat in order to
>>>>>>>> activate and configure async loggers is not convenient.
>>>>>>>>
>>>>>>>> There is also a more detailed email/blog post with some numbers we
>>>>>>>> collected being worked on.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Bruno
>>>>>>>>
>>>>>>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>>>>>>
>>>>>>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> No objection at all!
>>>>>>>>>
>>>>>>>>> I would like to add the tool to generate Custom/Extended Loggers,
>>>>>>>>> and do a doc fix for LOG4J2-631.
>>>>>>>>>
>>>>>>>>> Also, the site now has an empty section "Custom Plugins" under
>>>>>>>>> manual > Extending Log4j. Shall we remove that before the release?
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > I would like to do the release for Log4j 2.0 this weekend. Are
>>>>>>>>> there any objections?
>>>>>>>>> >
>>>>>>>>> > Ralph
>>>>>>>>> >
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>> > For additional commands, e-mail:
>>>>>>>>> log4j-dev-help@logging.apache.org
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Bruce Brouwer
>>>>> about.me/bruce.brouwer
>>>>> [image: Bruce Brouwer on about.me]
>>>>> <http://about.me/bruce.brouwer>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
> [image: Bruce Brouwer on about.me]
> <http://about.me/bruce.brouwer>
>
>
Re: Next release
Posted by Remko Popma <re...@gmail.com>.
I haven't studied StatusLogger in that much depth, but what you're saying sounds good. I agree with Ralph that this is for diagnostics and it's better to keep this simple.
Sent from my iPhone
> On 2014/07/14, at 8:19, Bruce Brouwer <br...@gmail.com> wrote:
>
> I'm all for making this more like a simple on/off switch. But the way things are setup right now, once you turn on the console logging, it can never be turned off. That is because once it is registered, nothing ever removes it.
>
> Are we ok with that?
>
> If we are, then I would like to remove all the level checking that is done in StatusLogger regarding these listeners and always have logs sent to the listeners. Let the listeners decide if they want to log something. Like was said, there are so few events it should be a performance issue.
>
>
>> On Sun, Jul 13, 2014 at 4:39 PM, Matt Sicker <bo...@gmail.com> wrote:
>> I agree with Ralph on all counts regarding StatusLogger. Really, anything that wants to store the StatusLogger output elsewhere is probably using standard out redirection.
>>
>>
>>> On 13 July 2014 15:34, Ralph Goers <ra...@dslextreme.com> wrote:
>>> Also, I am against renaming StatusLogger as it will result in modifications to hundreds of files.
>>>
>>> Ralph
>>>
>>>> On Jul 13, 2014, at 1:08 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>> Gary, the 2.0 release vote is already in progress. I don’t see adding an annotation or comment marking something as for internal use as a reason to hold up the release.
>>>>
>>>> No to renaming StatusLogger. It’s name is perfectly clear to me.
>>>>
>>>> Ralph
>>>>
>>>>> On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>
>>>>> I am hoping this will get cleaned up for the 2.0 release, especially if this affects the log4j-api module. As soon as we publish 2.0, folks will have a green light to implement their own loggers and solution and get hard-wired to the API. As a user, I would imagine that anything in log4j-api would be set in stone...
>>>>>
>>>>> While we are here: I always found the class name StatusLogger confusing (as is the package), for me InternalLogger (or PrivateLogger), would be clearer.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>> I suggest making an annotation or something to use for all the internal-use classes that are in log4j-api. It also helps to make internal use APIs all in separate packages from public APIs. That way you can make it extra obvious that if the internal API changes, too bad.
>>>>>>
>>>>>>
>>>>>>> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>>>>>>> Rats! It's not so simple as what I wrote.
>>>>>>>
>>>>>>> The crux of the problem is that the various Configuration classes need to control what shows up on the console from the StatusLogger. The way they've been doing that is finding the existing listener and reconfiguring it. There are some problems that will arise as you add new Configuration instances (e.g. multiple web apps sharing the same classloader) where these configurations build up over time. Additionally, nothing ever cleans them up as a configuration is reloaded so you might start logging at debug level to the console even though there is no configuration telling it to log at debug level. Also, depending on the order of reconfigurations, you might only be logging fatals to the console even though the current configuration is set to debug level.
>>>>>>>
>>>>>>> It seemed more appropriate to me to introduce a new concept, the StatusFilter. Since these are really trying to filter what shows up on the console, it seemed more appropriate than a listener. My solution to these problems is what brought about my API changes to StatusLogger, which is somewhat significant. But to solve these problems, I think my changes are necessary.
>>>>>>>
>>>>>>> If we consider these changes important enough, I'd like to get them in before 2.0, even though some may consider StatusLogger to not be "part of the API" even though it is in log4j-api.
>>>>>>>
>>>>>>> I checked in the first set of changes to the LOG4J2-609 branch.
>>>>>>>
>>>>>>> If we don't make these changes for 2.0, I really want to put JavaDoc on the stuff in ...log4j.status that clearly states this is for internal use only and may change in a breaking way in the future.
>>>>>>>
>>>>>>>
>>>>>>>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
>>>>>>>>> Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0 release. If you like it, we can put just that in trunk and release.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sounds good.
>>>>>>>>
>>>>>>>>>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed.
>>>>>>>>>> We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out.
>>>>>>>>>>
>>>>>>>>>> The only issue we had so far was about configuring async logger for all loggers. Having to pass system properties to Apache Tomcat in order to activate and configure async loggers is not convenient.
>>>>>>>>>>
>>>>>>>>>> There is also a more detailed email/blog post with some numbers we collected being worked on.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Bruno
>>>>>>>>>>
>>>>>>>>>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>>>>>>>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>> No objection at all!
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, the site now has an empty section "Custom Plugins" under manual > Extending Log4j. Shall we remove that before the release?
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> > I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>>>>>>>>>>>> >
>>>>>>>>>>>> > Ralph
>>>>>>>>>>>> > ---------------------------------------------------------------------
>>>>>>>>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Bruce Brouwer
>>>>>>> about.me/bruce.brouwer
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
>
>
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
Ok, the only test that didn't pass was the one testing for StatusLogger
writing to a file. I removed that test on the branch. If you review that
and think it worthy to go into the trunk, I'm pretty much on board with a
2.0 release (unless you think a short lived rc3 is in order).
On Sun, Jul 13, 2014 at 9:29 PM, Bruce Brouwer <br...@gmail.com>
wrote:
> Ok, this is starting to be simpler, as I'm sure you would all prefer. You
> can look at the branch LOG4J-609 again if you like. Here are the
> simplifications that I have made.
>
> 1) The listeners no longer report their level. They can decide if they
> want to do something with a status message in their log method.
> 2) There is no longer the option to configure the StatusLogger to write to
> a file.
> 3) I moved StatusConsoleListener out of log4j-api and into log4j-core,
> where we can probably get away with making more drastic changes to it in
> the future (so I can fix LOG4J-609)
>
> I have to check on the tests and stuff, but in general, I'm pretty happy
> with how small the impact is and in its ability to make a better solution
> for LOG4J-609 possible in the future.
>
>
> On Sun, Jul 13, 2014 at 8:23 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> This actually makes me wonder why you can configure the status logger
>> from a configuration file. Shouldn't this just be a system property or
>> something?
>>
>>
>> On 13 July 2014 18:57, Bruce Brouwer <br...@gmail.com> wrote:
>>
>>> The listener can be removed, but nothing ever does. Right now it can
>>> never know if it should be removed. And also, all that level checking is
>>> cached in StatusLogger. If all you do is change the status level of the
>>> listener it has no effect on the cached value in StatusLogger. It may end
>>> up having no effect.
>>>
>>> This is some of the stuff I was trying to clean up with my fix that I
>>> have been delinquent with.
>>>
>>> I will try to simplify this on the branch and see if it makes sense in
>>> the next hour or two.
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
> [image: Bruce Brouwer on about.me]
> <http://about.me/bruce.brouwer>
>
--
Bruce Brouwer
about.me/bruce.brouwer
[image: Bruce Brouwer on about.me]
<http://about.me/bruce.brouwer>
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
Ok, this is starting to be simpler, as I'm sure you would all prefer. You
can look at the branch LOG4J-609 again if you like. Here are the
simplifications that I have made.
1) The listeners no longer report their level. They can decide if they want
to do something with a status message in their log method.
2) There is no longer the option to configure the StatusLogger to write to
a file.
3) I moved StatusConsoleListener out of log4j-api and into log4j-core,
where we can probably get away with making more drastic changes to it in
the future (so I can fix LOG4J-609)
I have to check on the tests and stuff, but in general, I'm pretty happy
with how small the impact is and in its ability to make a better solution
for LOG4J-609 possible in the future.
On Sun, Jul 13, 2014 at 8:23 PM, Matt Sicker <bo...@gmail.com> wrote:
> This actually makes me wonder why you can configure the status logger from
> a configuration file. Shouldn't this just be a system property or something?
>
>
> On 13 July 2014 18:57, Bruce Brouwer <br...@gmail.com> wrote:
>
>> The listener can be removed, but nothing ever does. Right now it can
>> never know if it should be removed. And also, all that level checking is
>> cached in StatusLogger. If all you do is change the status level of the
>> listener it has no effect on the cached value in StatusLogger. It may end
>> up having no effect.
>>
>> This is some of the stuff I was trying to clean up with my fix that I
>> have been delinquent with.
>>
>> I will try to simplify this on the branch and see if it makes sense in
>> the next hour or two.
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Bruce Brouwer
about.me/bruce.brouwer
[image: Bruce Brouwer on about.me]
<http://about.me/bruce.brouwer>
Re: Next release
Posted by Matt Sicker <bo...@gmail.com>.
This actually makes me wonder why you can configure the status logger from
a configuration file. Shouldn't this just be a system property or something?
On 13 July 2014 18:57, Bruce Brouwer <br...@gmail.com> wrote:
> The listener can be removed, but nothing ever does. Right now it can never
> know if it should be removed. And also, all that level checking is cached
> in StatusLogger. If all you do is change the status level of the listener
> it has no effect on the cached value in StatusLogger. It may end up having
> no effect.
>
> This is some of the stuff I was trying to clean up with my fix that I have
> been delinquent with.
>
> I will try to simplify this on the branch and see if it makes sense in the
> next hour or two.
>
--
Matt Sicker <bo...@gmail.com>
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
The listener can be removed, but nothing ever does. Right now it can never
know if it should be removed. And also, all that level checking is cached
in StatusLogger. If all you do is change the status level of the listener
it has no effect on the cached value in StatusLogger. It may end up having
no effect.
This is some of the stuff I was trying to clean up with my fix that I have
been delinquent with.
I will try to simplify this on the branch and see if it makes sense in the
next hour or two.
Re: Next release
Posted by Ralph Goers <rg...@apache.org>.
If it can't be turned off that doesn't sound right. You should be able to get to the listener and change its level so that nothing is logged. I guess you are meaning the listener can't be removed? For some reason I thought it could.
Ralph
> On Jul 13, 2014, at 4:19 PM, Bruce Brouwer <br...@gmail.com> wrote:
>
> I'm all for making this more like a simple on/off switch. But the way things are setup right now, once you turn on the console logging, it can never be turned off. That is because once it is registered, nothing ever removes it.
>
> Are we ok with that?
>
> If we are, then I would like to remove all the level checking that is done in StatusLogger regarding these listeners and always have logs sent to the listeners. Let the listeners decide if they want to log something. Like was said, there are so few events it should be a performance issue.
>
>
>> On Sun, Jul 13, 2014 at 4:39 PM, Matt Sicker <bo...@gmail.com> wrote:
>> I agree with Ralph on all counts regarding StatusLogger. Really, anything that wants to store the StatusLogger output elsewhere is probably using standard out redirection.
>>
>>
>>> On 13 July 2014 15:34, Ralph Goers <ra...@dslextreme.com> wrote:
>>> Also, I am against renaming StatusLogger as it will result in modifications to hundreds of files.
>>>
>>> Ralph
>>>
>>>> On Jul 13, 2014, at 1:08 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>> Gary, the 2.0 release vote is already in progress. I don’t see adding an annotation or comment marking something as for internal use as a reason to hold up the release.
>>>>
>>>> No to renaming StatusLogger. It’s name is perfectly clear to me.
>>>>
>>>> Ralph
>>>>
>>>>> On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>
>>>>> I am hoping this will get cleaned up for the 2.0 release, especially if this affects the log4j-api module. As soon as we publish 2.0, folks will have a green light to implement their own loggers and solution and get hard-wired to the API. As a user, I would imagine that anything in log4j-api would be set in stone...
>>>>>
>>>>> While we are here: I always found the class name StatusLogger confusing (as is the package), for me InternalLogger (or PrivateLogger), would be clearer.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>> I suggest making an annotation or something to use for all the internal-use classes that are in log4j-api. It also helps to make internal use APIs all in separate packages from public APIs. That way you can make it extra obvious that if the internal API changes, too bad.
>>>>>>
>>>>>>
>>>>>>> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>>>>>>> Rats! It's not so simple as what I wrote.
>>>>>>>
>>>>>>> The crux of the problem is that the various Configuration classes need to control what shows up on the console from the StatusLogger. The way they've been doing that is finding the existing listener and reconfiguring it. There are some problems that will arise as you add new Configuration instances (e.g. multiple web apps sharing the same classloader) where these configurations build up over time. Additionally, nothing ever cleans them up as a configuration is reloaded so you might start logging at debug level to the console even though there is no configuration telling it to log at debug level. Also, depending on the order of reconfigurations, you might only be logging fatals to the console even though the current configuration is set to debug level.
>>>>>>>
>>>>>>> It seemed more appropriate to me to introduce a new concept, the StatusFilter. Since these are really trying to filter what shows up on the console, it seemed more appropriate than a listener. My solution to these problems is what brought about my API changes to StatusLogger, which is somewhat significant. But to solve these problems, I think my changes are necessary.
>>>>>>>
>>>>>>> If we consider these changes important enough, I'd like to get them in before 2.0, even though some may consider StatusLogger to not be "part of the API" even though it is in log4j-api.
>>>>>>>
>>>>>>> I checked in the first set of changes to the LOG4J2-609 branch.
>>>>>>>
>>>>>>> If we don't make these changes for 2.0, I really want to put JavaDoc on the stuff in ...log4j.status that clearly states this is for internal use only and may change in a breaking way in the future.
>>>>>>>
>>>>>>>
>>>>>>>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
>>>>>>>>> Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0 release. If you like it, we can put just that in trunk and release.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sounds good.
>>>>>>>>
>>>>>>>>>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed.
>>>>>>>>>> We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out.
>>>>>>>>>>
>>>>>>>>>> The only issue we had so far was about configuring async logger for all loggers. Having to pass system properties to Apache Tomcat in order to activate and configure async loggers is not convenient.
>>>>>>>>>>
>>>>>>>>>> There is also a more detailed email/blog post with some numbers we collected being worked on.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Bruno
>>>>>>>>>>
>>>>>>>>>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>>>>>>>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>>>>>>>>>> No objection at all!
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, the site now has an empty section "Custom Plugins" under manual > Extending Log4j. Shall we remove that before the release?
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> > I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>>>>>>>>>>>> >
>>>>>>>>>>>> > Ralph
>>>>>>>>>>>> > ---------------------------------------------------------------------
>>>>>>>>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Bruce Brouwer
>>>>>>> about.me/bruce.brouwer
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
>
>
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
I'm all for making this more like a simple on/off switch. But the way
things are setup right now, once you turn on the console logging, it can
never be turned off. That is because once it is registered, nothing ever
removes it.
Are we ok with that?
If we are, then I would like to remove all the level checking that is done
in StatusLogger regarding these listeners and always have logs sent to the
listeners. Let the listeners decide if they want to log something. Like was
said, there are so few events it should be a performance issue.
On Sun, Jul 13, 2014 at 4:39 PM, Matt Sicker <bo...@gmail.com> wrote:
> I agree with Ralph on all counts regarding StatusLogger. Really, anything
> that wants to store the StatusLogger output elsewhere is probably using
> standard out redirection.
>
>
> On 13 July 2014 15:34, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> Also, I am against renaming StatusLogger as it will result in
>> modifications to hundreds of files.
>>
>> Ralph
>>
>> On Jul 13, 2014, at 1:08 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> Gary, the 2.0 release vote is already in progress. I don’t see adding an
>> annotation or comment marking something as for internal use as a reason to
>> hold up the release.
>>
>> No to renaming StatusLogger. It’s name is perfectly clear to me.
>>
>> Ralph
>>
>> On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> I am hoping this will get cleaned up for the 2.0 release, especially if
>> this affects the log4j-api module. As soon as we publish 2.0, folks will
>> have a green light to implement their own loggers and solution and get
>> hard-wired to the API. As a user, I would imagine that anything in
>> log4j-api would be set in stone...
>>
>> While we are here: I always found the class name StatusLogger confusing
>> (as is the package), for me InternalLogger (or PrivateLogger), would be
>> clearer.
>>
>> Gary
>>
>>
>> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> I suggest making an annotation or something to use for all the
>>> internal-use classes that are in log4j-api. It also helps to make internal
>>> use APIs all in separate packages from public APIs. That way you can make
>>> it extra obvious that if the internal API changes, too bad.
>>>
>>>
>>> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>>>
>>>> Rats! It's not so simple as what I wrote.
>>>>
>>>> The crux of the problem is that the various Configuration classes need
>>>> to control what shows up on the console from the StatusLogger. The way
>>>> they've been doing that is finding the existing listener and reconfiguring
>>>> it. There are some problems that will arise as you add new Configuration
>>>> instances (e.g. multiple web apps sharing the same classloader) where these
>>>> configurations build up over time. Additionally, nothing ever cleans them
>>>> up as a configuration is reloaded so you might start logging at debug level
>>>> to the console even though there is no configuration telling it to log at
>>>> debug level. Also, depending on the order of reconfigurations, you might
>>>> only be logging fatals to the console even though the current configuration
>>>> is set to debug level.
>>>>
>>>> It seemed more appropriate to me to introduce a new concept, the
>>>> StatusFilter. Since these are really trying to filter what shows up on the
>>>> console, it seemed more appropriate than a listener. My solution to these
>>>> problems is what brought about my API changes to StatusLogger, which is
>>>> somewhat significant. But to solve these problems, I think my changes are
>>>> necessary.
>>>>
>>>> If we consider these changes important enough, I'd like to get them in
>>>> before 2.0, even though some may consider StatusLogger to not be "part of
>>>> the API" even though it is in log4j-api.
>>>>
>>>> I checked in the first set of changes to the LOG4J2-609 branch.
>>>>
>>>> If we don't make these changes for 2.0, I really want to put JavaDoc on
>>>> the stuff in ...log4j.status that clearly states this is for internal use
>>>> only and may change in a breaking way in the future.
>>>>
>>>>
>>>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Here is what I am thinking. I will make the branch tomorrow and put
>>>>>> just the minimal changes in place with the modified StatusLogger api. This
>>>>>> way when I fix things completely we won't have a breaking api change after
>>>>>> 2.0 release. If you like it, we can put just that in trunk and release.
>>>>>>
>>>>> Sounds good.
>>>>>
>>>>>
>>>>>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks
>>>>>>> and have been very impressed.
>>>>>>> We are in the process of migrating our services to Apache Log 2.0rc2
>>>>>>> so they can be ready for roll out when 2.0 comes out.
>>>>>>>
>>>>>>> The only issue we had so far was about configuring async logger for
>>>>>>> all loggers. Having to pass system properties to Apache Tomcat in order to
>>>>>>> activate and configure async loggers is not convenient.
>>>>>>>
>>>>>>> There is also a more detailed email/blog post with some numbers we
>>>>>>> collected being worked on.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bruno
>>>>>>>
>>>>>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>>>>>
>>>>>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>>>>>
>>>>>>>
>>>>>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>>>>>
>>>>>>>> No objection at all!
>>>>>>>>
>>>>>>>> I would like to add the tool to generate Custom/Extended Loggers,
>>>>>>>> and do a doc fix for LOG4J2-631.
>>>>>>>>
>>>>>>>> Also, the site now has an empty section "Custom Plugins" under
>>>>>>>> manual > Extending Log4j. Shall we remove that before the release?
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> > I would like to do the release for Log4j 2.0 this weekend. Are
>>>>>>>> there any objections?
>>>>>>>> >
>>>>>>>> > Ralph
>>>>>>>> >
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>> > For additional commands, e-mail:
>>>>>>>> log4j-dev-help@logging.apache.org
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Bruce Brouwer
>>>> about.me/bruce.brouwer
>>>> [image: Bruce Brouwer on about.me]
>>>> <http://about.me/bruce.brouwer>
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Bruce Brouwer
about.me/bruce.brouwer
[image: Bruce Brouwer on about.me]
<http://about.me/bruce.brouwer>
Re: Next release
Posted by Matt Sicker <bo...@gmail.com>.
I agree with Ralph on all counts regarding StatusLogger. Really, anything
that wants to store the StatusLogger output elsewhere is probably using
standard out redirection.
On 13 July 2014 15:34, Ralph Goers <ra...@dslextreme.com> wrote:
> Also, I am against renaming StatusLogger as it will result in
> modifications to hundreds of files.
>
> Ralph
>
> On Jul 13, 2014, at 1:08 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> Gary, the 2.0 release vote is already in progress. I don’t see adding an
> annotation or comment marking something as for internal use as a reason to
> hold up the release.
>
> No to renaming StatusLogger. It’s name is perfectly clear to me.
>
> Ralph
>
> On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> I am hoping this will get cleaned up for the 2.0 release, especially if
> this affects the log4j-api module. As soon as we publish 2.0, folks will
> have a green light to implement their own loggers and solution and get
> hard-wired to the API. As a user, I would imagine that anything in
> log4j-api would be set in stone...
>
> While we are here: I always found the class name StatusLogger confusing
> (as is the package), for me InternalLogger (or PrivateLogger), would be
> clearer.
>
> Gary
>
>
> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> I suggest making an annotation or something to use for all the
>> internal-use classes that are in log4j-api. It also helps to make internal
>> use APIs all in separate packages from public APIs. That way you can make
>> it extra obvious that if the internal API changes, too bad.
>>
>>
>> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>>
>>> Rats! It's not so simple as what I wrote.
>>>
>>> The crux of the problem is that the various Configuration classes need
>>> to control what shows up on the console from the StatusLogger. The way
>>> they've been doing that is finding the existing listener and reconfiguring
>>> it. There are some problems that will arise as you add new Configuration
>>> instances (e.g. multiple web apps sharing the same classloader) where these
>>> configurations build up over time. Additionally, nothing ever cleans them
>>> up as a configuration is reloaded so you might start logging at debug level
>>> to the console even though there is no configuration telling it to log at
>>> debug level. Also, depending on the order of reconfigurations, you might
>>> only be logging fatals to the console even though the current configuration
>>> is set to debug level.
>>>
>>> It seemed more appropriate to me to introduce a new concept, the
>>> StatusFilter. Since these are really trying to filter what shows up on the
>>> console, it seemed more appropriate than a listener. My solution to these
>>> problems is what brought about my API changes to StatusLogger, which is
>>> somewhat significant. But to solve these problems, I think my changes are
>>> necessary.
>>>
>>> If we consider these changes important enough, I'd like to get them in
>>> before 2.0, even though some may consider StatusLogger to not be "part of
>>> the API" even though it is in log4j-api.
>>>
>>> I checked in the first set of changes to the LOG4J2-609 branch.
>>>
>>> If we don't make these changes for 2.0, I really want to put JavaDoc on
>>> the stuff in ...log4j.status that clearly states this is for internal use
>>> only and may change in a breaking way in the future.
>>>
>>>
>>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com>
>>>> wrote:
>>>>
>>>>> Here is what I am thinking. I will make the branch tomorrow and put
>>>>> just the minimal changes in place with the modified StatusLogger api. This
>>>>> way when I fix things completely we won't have a breaking api change after
>>>>> 2.0 release. If you like it, we can put just that in trunk and release.
>>>>>
>>>> Sounds good.
>>>>
>>>>
>>>>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and
>>>>>> have been very impressed.
>>>>>> We are in the process of migrating our services to Apache Log 2.0rc2
>>>>>> so they can be ready for roll out when 2.0 comes out.
>>>>>>
>>>>>> The only issue we had so far was about configuring async logger for
>>>>>> all loggers. Having to pass system properties to Apache Tomcat in order to
>>>>>> activate and configure async loggers is not convenient.
>>>>>>
>>>>>> There is also a more detailed email/blog post with some numbers we
>>>>>> collected being worked on.
>>>>>>
>>>>>> Thanks,
>>>>>> Bruno
>>>>>>
>>>>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>>>>
>>>>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>>>>
>>>>>>
>>>>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>>>>
>>>>>>> No objection at all!
>>>>>>>
>>>>>>> I would like to add the tool to generate Custom/Extended Loggers,
>>>>>>> and do a doc fix for LOG4J2-631.
>>>>>>>
>>>>>>> Also, the site now has an empty section "Custom Plugins" under
>>>>>>> manual > Extending Log4j. Shall we remove that before the release?
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > I would like to do the release for Log4j 2.0 this weekend. Are
>>>>>>> there any objections?
>>>>>>> >
>>>>>>> > Ralph
>>>>>>> >
>>>>>>> ---------------------------------------------------------------------
>>>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>> >
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Bruce Brouwer
>>> about.me/bruce.brouwer
>>> [image: Bruce Brouwer on about.me]
>>> <http://about.me/bruce.brouwer>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Next release
Posted by Ralph Goers <ra...@dslextreme.com>.
Also, I am against renaming StatusLogger as it will result in modifications to hundreds of files.
Ralph
On Jul 13, 2014, at 1:08 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> Gary, the 2.0 release vote is already in progress. I don’t see adding an annotation or comment marking something as for internal use as a reason to hold up the release.
>
> No to renaming StatusLogger. It’s name is perfectly clear to me.
>
> Ralph
>
> On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> I am hoping this will get cleaned up for the 2.0 release, especially if this affects the log4j-api module. As soon as we publish 2.0, folks will have a green light to implement their own loggers and solution and get hard-wired to the API. As a user, I would imagine that anything in log4j-api would be set in stone...
>>
>> While we are here: I always found the class name StatusLogger confusing (as is the package), for me InternalLogger (or PrivateLogger), would be clearer.
>>
>> Gary
>>
>>
>> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>> I suggest making an annotation or something to use for all the internal-use classes that are in log4j-api. It also helps to make internal use APIs all in separate packages from public APIs. That way you can make it extra obvious that if the internal API changes, too bad.
>>
>>
>> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>> Rats! It's not so simple as what I wrote.
>>
>> The crux of the problem is that the various Configuration classes need to control what shows up on the console from the StatusLogger. The way they've been doing that is finding the existing listener and reconfiguring it. There are some problems that will arise as you add new Configuration instances (e.g. multiple web apps sharing the same classloader) where these configurations build up over time. Additionally, nothing ever cleans them up as a configuration is reloaded so you might start logging at debug level to the console even though there is no configuration telling it to log at debug level. Also, depending on the order of reconfigurations, you might only be logging fatals to the console even though the current configuration is set to debug level.
>>
>> It seemed more appropriate to me to introduce a new concept, the StatusFilter. Since these are really trying to filter what shows up on the console, it seemed more appropriate than a listener. My solution to these problems is what brought about my API changes to StatusLogger, which is somewhat significant. But to solve these problems, I think my changes are necessary.
>>
>> If we consider these changes important enough, I'd like to get them in before 2.0, even though some may consider StatusLogger to not be "part of the API" even though it is in log4j-api.
>>
>> I checked in the first set of changes to the LOG4J2-609 branch.
>>
>> If we don't make these changes for 2.0, I really want to put JavaDoc on the stuff in ...log4j.status that clearly states this is for internal use only and may change in a breaking way in the future.
>>
>>
>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com> wrote:
>>
>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
>> Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0 release. If you like it, we can put just that in trunk and release.
>>
>> Sounds good.
>>
>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>> Hi,
>>
>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed.
>> We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out.
>>
>> The only issue we had so far was about configuring async logger for all loggers. Having to pass system properties to Apache Tomcat in order to activate and configure async loggers is not convenient.
>>
>> There is also a more detailed email/blog post with some numbers we collected being worked on.
>>
>> Thanks,
>> Bruno
>>
>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>
>>>
>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>> No objection at all!
>>>
>>> I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631.
>>>
>>> Also, the site now has an empty section "Custom Plugins" under manual > Extending Log4j. Shall we remove that before the release?
>>>
>>> Sent from my iPhone
>>>
>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
>>> >
>>> > I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>>> >
>>> > Ralph
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>> --
>>
>>
>> Bruce Brouwer
>> about.me/bruce.brouwer
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
Re: Next release
Posted by Ralph Goers <ra...@dslextreme.com>.
Gary, the 2.0 release vote is already in progress. I don’t see adding an annotation or comment marking something as for internal use as a reason to hold up the release.
No to renaming StatusLogger. It’s name is perfectly clear to me.
Ralph
On Jul 13, 2014, at 1:04 PM, Gary Gregory <ga...@gmail.com> wrote:
> I am hoping this will get cleaned up for the 2.0 release, especially if this affects the log4j-api module. As soon as we publish 2.0, folks will have a green light to implement their own loggers and solution and get hard-wired to the API. As a user, I would imagine that anything in log4j-api would be set in stone...
>
> While we are here: I always found the class name StatusLogger confusing (as is the package), for me InternalLogger (or PrivateLogger), would be clearer.
>
> Gary
>
>
> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
> I suggest making an annotation or something to use for all the internal-use classes that are in log4j-api. It also helps to make internal use APIs all in separate packages from public APIs. That way you can make it extra obvious that if the internal API changes, too bad.
>
>
> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
> Rats! It's not so simple as what I wrote.
>
> The crux of the problem is that the various Configuration classes need to control what shows up on the console from the StatusLogger. The way they've been doing that is finding the existing listener and reconfiguring it. There are some problems that will arise as you add new Configuration instances (e.g. multiple web apps sharing the same classloader) where these configurations build up over time. Additionally, nothing ever cleans them up as a configuration is reloaded so you might start logging at debug level to the console even though there is no configuration telling it to log at debug level. Also, depending on the order of reconfigurations, you might only be logging fatals to the console even though the current configuration is set to debug level.
>
> It seemed more appropriate to me to introduce a new concept, the StatusFilter. Since these are really trying to filter what shows up on the console, it seemed more appropriate than a listener. My solution to these problems is what brought about my API changes to StatusLogger, which is somewhat significant. But to solve these problems, I think my changes are necessary.
>
> If we consider these changes important enough, I'd like to get them in before 2.0, even though some may consider StatusLogger to not be "part of the API" even though it is in log4j-api.
>
> I checked in the first set of changes to the LOG4J2-609 branch.
>
> If we don't make these changes for 2.0, I really want to put JavaDoc on the stuff in ...log4j.status that clearly states this is for internal use only and may change in a breaking way in the future.
>
>
> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com> wrote:
>
> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
> Here is what I am thinking. I will make the branch tomorrow and put just the minimal changes in place with the modified StatusLogger api. This way when I fix things completely we won't have a breaking api change after 2.0 release. If you like it, we can put just that in trunk and release.
>
> Sounds good.
>
> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
> Hi,
>
> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very impressed.
> We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready for roll out when 2.0 comes out.
>
> The only issue we had so far was about configuring async logger for all loggers. Having to pass system properties to Apache Tomcat in order to activate and configure async loggers is not convenient.
>
> There is also a more detailed email/blog post with some numbers we collected being worked on.
>
> Thanks,
> Bruno
>
> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>
>>
>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>> No objection at all!
>>
>> I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631.
>>
>> Also, the site now has an empty section "Custom Plugins" under manual > Extending Log4j. Shall we remove that before the release?
>>
>> Sent from my iPhone
>>
>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
>> >
>> > I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>> >
>> > Ralph
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: Next release
Posted by Gary Gregory <ga...@gmail.com>.
I am hoping this will get cleaned up for the 2.0 release, especially if
this affects the log4j-api module. As soon as we publish 2.0, folks will
have a green light to implement their own loggers and solution and get
hard-wired to the API. As a user, I would imagine that anything in
log4j-api would be set in stone...
While we are here: I always found the class name StatusLogger confusing (as
is the package), for me InternalLogger (or PrivateLogger), would be
clearer.
Gary
On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
> I suggest making an annotation or something to use for all the
> internal-use classes that are in log4j-api. It also helps to make internal
> use APIs all in separate packages from public APIs. That way you can make
> it extra obvious that if the internal API changes, too bad.
>
>
> On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
>
>> Rats! It's not so simple as what I wrote.
>>
>> The crux of the problem is that the various Configuration classes need to
>> control what shows up on the console from the StatusLogger. The way they've
>> been doing that is finding the existing listener and reconfiguring it.
>> There are some problems that will arise as you add new Configuration
>> instances (e.g. multiple web apps sharing the same classloader) where these
>> configurations build up over time. Additionally, nothing ever cleans them
>> up as a configuration is reloaded so you might start logging at debug level
>> to the console even though there is no configuration telling it to log at
>> debug level. Also, depending on the order of reconfigurations, you might
>> only be logging fatals to the console even though the current configuration
>> is set to debug level.
>>
>> It seemed more appropriate to me to introduce a new concept, the
>> StatusFilter. Since these are really trying to filter what shows up on the
>> console, it seemed more appropriate than a listener. My solution to these
>> problems is what brought about my API changes to StatusLogger, which is
>> somewhat significant. But to solve these problems, I think my changes are
>> necessary.
>>
>> If we consider these changes important enough, I'd like to get them in
>> before 2.0, even though some may consider StatusLogger to not be "part of
>> the API" even though it is in log4j-api.
>>
>> I checked in the first set of changes to the LOG4J2-609 branch.
>>
>> If we don't make these changes for 2.0, I really want to put JavaDoc on
>> the stuff in ...log4j.status that clearly states this is for internal use
>> only and may change in a breaking way in the future.
>>
>>
>> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>>
>>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
>>>
>>>> Here is what I am thinking. I will make the branch tomorrow and put
>>>> just the minimal changes in place with the modified StatusLogger api. This
>>>> way when I fix things completely we won't have a breaking api change after
>>>> 2.0 release. If you like it, we can put just that in trunk and release.
>>>>
>>> Sounds good.
>>>
>>>
>>>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and
>>>>> have been very impressed.
>>>>> We are in the process of migrating our services to Apache Log 2.0rc2
>>>>> so they can be ready for roll out when 2.0 comes out.
>>>>>
>>>>> The only issue we had so far was about configuring async logger for
>>>>> all loggers. Having to pass system properties to Apache Tomcat in order to
>>>>> activate and configure async loggers is not convenient.
>>>>>
>>>>> There is also a more detailed email/blog post with some numbers we
>>>>> collected being worked on.
>>>>>
>>>>> Thanks,
>>>>> Bruno
>>>>>
>>>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>>>
>>>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>>>
>>>>>
>>>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>>>
>>>>>> No objection at all!
>>>>>>
>>>>>> I would like to add the tool to generate Custom/Extended Loggers, and
>>>>>> do a doc fix for LOG4J2-631.
>>>>>>
>>>>>> Also, the site now has an empty section "Custom Plugins" under manual
>>>>>> > Extending Log4j. Shall we remove that before the release?
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > I would like to do the release for Log4j 2.0 this weekend. Are
>>>>>> there any objections?
>>>>>> >
>>>>>> > Ralph
>>>>>> >
>>>>>> ---------------------------------------------------------------------
>>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>> >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>
>>
>> --
>>
>>
>> Bruce Brouwer
>> about.me/bruce.brouwer
>> [image: Bruce Brouwer on about.me]
>> <http://about.me/bruce.brouwer>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Next release
Posted by Matt Sicker <bo...@gmail.com>.
I suggest making an annotation or something to use for all the internal-use
classes that are in log4j-api. It also helps to make internal use APIs all
in separate packages from public APIs. That way you can make it extra
obvious that if the internal API changes, too bad.
On 13 July 2014 13:44, Bruce Brouwer <br...@gmail.com> wrote:
> Rats! It's not so simple as what I wrote.
>
> The crux of the problem is that the various Configuration classes need to
> control what shows up on the console from the StatusLogger. The way they've
> been doing that is finding the existing listener and reconfiguring it.
> There are some problems that will arise as you add new Configuration
> instances (e.g. multiple web apps sharing the same classloader) where these
> configurations build up over time. Additionally, nothing ever cleans them
> up as a configuration is reloaded so you might start logging at debug level
> to the console even though there is no configuration telling it to log at
> debug level. Also, depending on the order of reconfigurations, you might
> only be logging fatals to the console even though the current configuration
> is set to debug level.
>
> It seemed more appropriate to me to introduce a new concept, the
> StatusFilter. Since these are really trying to filter what shows up on the
> console, it seemed more appropriate than a listener. My solution to these
> problems is what brought about my API changes to StatusLogger, which is
> somewhat significant. But to solve these problems, I think my changes are
> necessary.
>
> If we consider these changes important enough, I'd like to get them in
> before 2.0, even though some may consider StatusLogger to not be "part of
> the API" even though it is in log4j-api.
>
> I checked in the first set of changes to the LOG4J2-609 branch.
>
> If we don't make these changes for 2.0, I really want to put JavaDoc on
> the stuff in ...log4j.status that clearly states this is for internal use
> only and may change in a breaking way in the future.
>
>
> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com>
> wrote:
>
>>
>> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
>>
>>> Here is what I am thinking. I will make the branch tomorrow and put just
>>> the minimal changes in place with the modified StatusLogger api. This way
>>> when I fix things completely we won't have a breaking api change after 2.0
>>> release. If you like it, we can put just that in trunk and release.
>>>
>> Sounds good.
>>
>>
>>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>>
>>>> Hi,
>>>>
>>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and
>>>> have been very impressed.
>>>> We are in the process of migrating our services to Apache Log 2.0rc2 so
>>>> they can be ready for roll out when 2.0 comes out.
>>>>
>>>> The only issue we had so far was about configuring async logger for all
>>>> loggers. Having to pass system properties to Apache Tomcat in order to
>>>> activate and configure async loggers is not convenient.
>>>>
>>>> There is also a more detailed email/blog post with some numbers we
>>>> collected being worked on.
>>>>
>>>> Thanks,
>>>> Bruno
>>>>
>>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>>
>>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>>
>>>>
>>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>>
>>>>> No objection at all!
>>>>>
>>>>> I would like to add the tool to generate Custom/Extended Loggers, and
>>>>> do a doc fix for LOG4J2-631.
>>>>>
>>>>> Also, the site now has an empty section "Custom Plugins" under manual
>>>>> > Extending Log4j. Shall we remove that before the release?
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>> >
>>>>> > I would like to do the release for Log4j 2.0 this weekend. Are there
>>>>> any objections?
>>>>> >
>>>>> > Ralph
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
> [image: Bruce Brouwer on about.me]
> <http://about.me/bruce.brouwer>
>
--
Matt Sicker <bo...@gmail.com>
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
Rats! It's not so simple as what I wrote.
The crux of the problem is that the various Configuration classes need to
control what shows up on the console from the StatusLogger. The way they've
been doing that is finding the existing listener and reconfiguring it.
There are some problems that will arise as you add new Configuration
instances (e.g. multiple web apps sharing the same classloader) where these
configurations build up over time. Additionally, nothing ever cleans them
up as a configuration is reloaded so you might start logging at debug level
to the console even though there is no configuration telling it to log at
debug level. Also, depending on the order of reconfigurations, you might
only be logging fatals to the console even though the current configuration
is set to debug level.
It seemed more appropriate to me to introduce a new concept, the
StatusFilter. Since these are really trying to filter what shows up on the
console, it seemed more appropriate than a listener. My solution to these
problems is what brought about my API changes to StatusLogger, which is
somewhat significant. But to solve these problems, I think my changes are
necessary.
If we consider these changes important enough, I'd like to get them in
before 2.0, even though some may consider StatusLogger to not be "part of
the API" even though it is in log4j-api.
I checked in the first set of changes to the LOG4J2-609 branch.
If we don't make these changes for 2.0, I really want to put JavaDoc on the
stuff in ...log4j.status that clearly states this is for internal use only
and may change in a breaking way in the future.
On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <re...@gmail.com> wrote:
>
> On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
>
>> Here is what I am thinking. I will make the branch tomorrow and put just
>> the minimal changes in place with the modified StatusLogger api. This way
>> when I fix things completely we won't have a breaking api change after 2.0
>> release. If you like it, we can put just that in trunk and release.
>>
> Sounds good.
>
>
>> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
>>
>>> Hi,
>>>
>>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and
>>> have been very impressed.
>>> We are in the process of migrating our services to Apache Log 2.0rc2 so
>>> they can be ready for roll out when 2.0 comes out.
>>>
>>> The only issue we had so far was about configuring async logger for all
>>> loggers. Having to pass system properties to Apache Tomcat in order to
>>> activate and configure async loggers is not convenient.
>>>
>>> There is also a more detailed email/blog post with some numbers we
>>> collected being worked on.
>>>
>>> Thanks,
>>> Bruno
>>>
>>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>>
>>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>>
>>>
>>> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>>>
>>>> No objection at all!
>>>>
>>>> I would like to add the tool to generate Custom/Extended Loggers, and
>>>> do a doc fix for LOG4J2-631.
>>>>
>>>> Also, the site now has an empty section "Custom Plugins" under manual >
>>>> Extending Log4j. Shall we remove that before the release?
>>>>
>>>> Sent from my iPhone
>>>>
>>>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>> >
>>>> > I would like to do the release for Log4j 2.0 this weekend. Are there
>>>> any objections?
>>>> >
>>>> > Ralph
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
--
Bruce Brouwer
about.me/bruce.brouwer
[image: Bruce Brouwer on about.me]
<http://about.me/bruce.brouwer>
Re: Next release
Posted by Remko Popma <re...@gmail.com>.
On Sunday, July 13, 2014, Bruce Brouwer <br...@gmail.com> wrote:
> Here is what I am thinking. I will make the branch tomorrow and put just
> the minimal changes in place with the modified StatusLogger api. This way
> when I fix things completely we won't have a breaking api change after 2.0
> release. If you like it, we can put just that in trunk and release.
>
Sounds good.
> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bmahe@tango.me
> <javascript:_e(%7B%7D,'cvml','bmahe@tango.me');>> wrote:
>
>> Hi,
>>
>> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and
>> have been very impressed.
>> We are in the process of migrating our services to Apache Log 2.0rc2 so
>> they can be ready for roll out when 2.0 comes out.
>>
>> The only issue we had so far was about configuring async logger for all
>> loggers. Having to pass system properties to Apache Tomcat in order to
>> activate and configure async loggers is not convenient.
>>
>> There is also a more detailed email/blog post with some numbers we
>> collected being worked on.
>>
>> Thanks,
>> Bruno
>>
>> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>>
>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>>
>>
>> On 11 July 2014 03:58, Remko Popma <remko.popma@gmail.com
>> <javascript:_e(%7B%7D,'cvml','remko.popma@gmail.com');>> wrote:
>>
>>> No objection at all!
>>>
>>> I would like to add the tool to generate Custom/Extended Loggers, and do
>>> a doc fix for LOG4J2-631.
>>>
>>> Also, the site now has an empty section "Custom Plugins" under manual >
>>> Extending Log4j. Shall we remove that before the release?
>>>
>>> Sent from my iPhone
>>>
>>> > On 2014/07/11, at 15:50, Ralph Goers <ralph.goers@dslextreme.com
>>> <javascript:_e(%7B%7D,'cvml','ralph.goers@dslextreme.com');>> wrote:
>>> >
>>> > I would like to do the release for Log4j 2.0 this weekend. Are there
>>> any objections?
>>> >
>>> > Ralph
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> <javascript:_e(%7B%7D,'cvml','log4j-dev-unsubscribe@logging.apache.org');>
>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> <javascript:_e(%7B%7D,'cvml','log4j-dev-help@logging.apache.org');>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> <javascript:_e(%7B%7D,'cvml','log4j-dev-unsubscribe@logging.apache.org');>
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> <javascript:_e(%7B%7D,'cvml','log4j-dev-help@logging.apache.org');>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com
>> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
>>
>>
>>
Re: Next release
Posted by Bruce Brouwer <br...@gmail.com>.
Here is what I am thinking. I will make the branch tomorrow and put just
the minimal changes in place with the modified StatusLogger api. This way
when I fix things completely we won't have a breaking api change after 2.0
release. If you like it, we can put just that in trunk and release.
On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bm...@tango.me> wrote:
> Hi,
>
> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have
> been very impressed.
> We are in the process of migrating our services to Apache Log 2.0rc2 so
> they can be ready for roll out when 2.0 comes out.
>
> The only issue we had so far was about configuring async logger for all
> loggers. Having to pass system properties to Apache Tomcat in order to
> activate and configure async loggers is not convenient.
>
> There is also a more detailed email/blog post with some numbers we
> collected being worked on.
>
> Thanks,
> Bruno
>
> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>
> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>
>
> On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
>
>> No objection at all!
>>
>> I would like to add the tool to generate Custom/Extended Loggers, and do
>> a doc fix for LOG4J2-631.
>>
>> Also, the site now has an empty section "Custom Plugins" under manual >
>> Extending Log4j. Shall we remove that before the release?
>>
>> Sent from my iPhone
>>
>> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>> >
>> > I would like to do the release for Log4j 2.0 this weekend. Are there
>> any objections?
>> >
>> > Ralph
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
Re: Next release
Posted by Bruno Mahé <bm...@tango.me>.
Hi,
We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and
have been very impressed.
We are in the process of migrating our services to Apache Log 2.0rc2 so
they can be ready for roll out when 2.0 comes out.
The only issue we had so far was about configuring async logger for all
loggers. Having to pass system properties to Apache Tomcat in order to
activate and configure async loggers is not convenient.
There is also a more detailed email/blog post with some numbers we
collected being worked on.
Thanks,
Bruno
On 07/11/2014 05:50 AM, Matt Sicker wrote:
> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>
>
> On 11 July 2014 03:58, Remko Popma <remko.popma@gmail.com
> <ma...@gmail.com>> wrote:
>
> No objection at all!
>
> I would like to add the tool to generate Custom/Extended Loggers,
> and do a doc fix for LOG4J2-631.
>
> Also, the site now has an empty section "Custom Plugins" under
> manual > Extending Log4j. Shall we remove that before the release?
>
> Sent from my iPhone
>
> > On 2014/07/11, at 15:50, Ralph Goers <ralph.goers@dslextreme.com
> <ma...@dslextreme.com>> wrote:
> >
> > I would like to do the release for Log4j 2.0 this weekend. Are
> there any objections?
> >
> > Ralph
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> <ma...@logging.apache.org>
> > For additional commands, e-mail:
> log4j-dev-help@logging.apache.org
> <ma...@logging.apache.org>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> <ma...@logging.apache.org>
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> <ma...@logging.apache.org>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Next release
Posted by Matt Sicker <bo...@gmail.com>.
Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
On 11 July 2014 03:58, Remko Popma <re...@gmail.com> wrote:
> No objection at all!
>
> I would like to add the tool to generate Custom/Extended Loggers, and do a
> doc fix for LOG4J2-631.
>
> Also, the site now has an empty section "Custom Plugins" under manual >
> Extending Log4j. Shall we remove that before the release?
>
> Sent from my iPhone
>
> > On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
> >
> > I would like to do the release for Log4j 2.0 this weekend. Are there any
> objections?
> >
> > Ralph
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Next release
Posted by Remko Popma <re...@gmail.com>.
No objection at all!
I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix for LOG4J2-631.
Also, the site now has an empty section "Custom Plugins" under manual > Extending Log4j. Shall we remove that before the release?
Sent from my iPhone
> On 2014/07/11, at 15:50, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org