logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudharma Puranik <sudharma.pura...@gmail.com>
Subject Re: Stable release date for Log4j2
Date Fri, 19 Jul 2013 05:18:11 GMT
Can you borrow the kind of similar implementation done in logback? just my
2 cents?


On Wed, Jul 17, 2013 at 6:25 PM, Ralph Goers <rgoers@apache.org> wrote:

> Stopping the Appender is not going to cause a rollover. You need a
> rollover policy that you can call that will then return true the next time
> it is accessed. You then have to log between 1-16 events as the policy is
> only checked every 16 events. Eliminating the need to have events be logged
> to cause the rollover is the main issue I have faced in trying to implement
> this.
>
> Ralph
>
> On Jul 16, 2013, at 10:42 PM, Sudharma Puranik <sudharma.puranik@gmail.com>
> wrote:
>
> Is there any way of having a workaround for a forcerollover. ? What I was
> thinking that instead of having a force roll over , I can just stop the
> appender . But I have a problem like when I restart the appender I am
> getting error like ,  *ERROR Attempted to append to non-started appender
> dumpAppender*
>
>
> If I am correct , If I reconfigure the context then I think I would be
> losing my events? Is there any way that I stop and start appenders as and
> when needed, of course without reconfiguring the context?
>
> Please correct me if my understanding is wrong in any case.
>
> -sudharma
>
>
> On Tue, Jul 16, 2013 at 9:39 AM, Sudharma Puranik <
> sudharma.puranik@gmail.com> wrote:
>
>> Hi Ralph,
>>
>> Thank you for your detailed explanation It was really helpful. Definitely
>> I will go through this one
>>
>> -Sudharma
>>
>>
>> On Mon, Jul 15, 2013 at 9:21 PM, Ralph Goers <ralph.goers@dslextreme.com>wrote:
>>
>>> First, yes it is probably more complicated creating Appenders in Log4j 2
>>> than in Logback.  One of the differences between the two is that when
>>> Logback detects changes to its configuration it first clears the existing
>>> configuration before it starts to reconfigure. So while it is processing
>>> the new configuration log events are being lost. Log4j 2 treats the
>>> configuration as an atomic unit.  Managers are used so that OutputStreams
>>> and Sockets do not have to be closed across reconfigurations if they don't
>>> need to be.
>>>
>>> Creating a policy should be rather easy and straightforward.
>>>
>>> The best way to add Appenders is to create your own Configuration class,
>>> either by extending one of the existing implementations or by extending
>>> BaseConfiguration.  The benefit with this is when a reconfiguration occurs
>>> (if you choose to support it) your appenders, etc will be recreated.  As an
>>> alternative you can do
>>>
>>> Appender appender = createMyAppender();
>>> appender.start();
>>> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>>> Configuration config = ctx.getConfiguration();
>>> config.addLoggerAppender(logger, appender);
>>>
>>> Note though, that if the configuration is modified and reloaded this
>>> appender will be removed an not re-added.
>>>
>>> I should also point out that if you don't want the benefits using a
>>> Manager you don't have to. In addition, if you only want your components to
>>> be added programmatically you don't have to use the Plugin mechanism.  In
>>> this case you would simply create a class that implements the Appender
>>> interface.
>>>
>>> The request for a programmatic way to force a rollover is captured in
>>> https://issues.apache.org/jira/browse/LOG4J2-89.  I started to
>>> investigate this several months ago but didn't complete it as I was having
>>> trouble figuring out how to do the rollover in a safe manner. I'd like to
>>> get back to this soon as a number of people have asked about it.
>>>
>>> Ralph
>>>
>>>
>>> On Jul 15, 2013, at 4:13 AM, Sudharma Puranik wrote:
>>>
>>> Hi Ralph,
>>>
>>> I have a scenario to create Appenders programmatically and so also the
>>> Policies. I am finding it difficult to create each entity since Appender
>>> delegates everything with RollingFileManager, and which is not hooked with
>>> Appender. I have 2 questions like,
>>>
>>> 1. Does log4j support declarative and refrain from programmatically
>>> creating the log configurations?
>>> 2. Logback gives the flexibility to extend Appenders and also the
>>> TriggeringPolicies with which I can customise my logging.
>>>
>>> Previously I had a scenario where I had to do a forceRollover in program
>>> for monitoring reasons . This was easily achievable by logback by calling
>>> the rollover of RollingFileAppender which is delegated to Policy.  This I
>>> am unable to do with Log4j 2,  or rather I feel it is much more complex.
>>>
>>> Could you please help me in finding a better way, I had enough search on
>>> google but couldnt find a suitable usecase.
>>>
>>> -Sudharma
>>>
>>>
>>> On Mon, Jul 15, 2013 at 8:34 AM, Sudharma Puranik <
>>> sudharma.puranik@gmail.com> wrote:
>>>
>>>> OK fine .  I will meanwhile evaluate the same as well .
>>>> On 14 Jul 2013 20:52, "Ralph Goers" <ralph.goers@dslextreme.com> wrote:
>>>>
>>>>> OK - I can't make any promises because it is really up to the
>>>>> community. But we have been saying for some time that our target was
to get
>>>>> a 2.0 GA release this summer.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Jul 14, 2013, at 7:20 AM, Sudharma Puranik wrote:
>>>>>
>>>>> To be frank , I havent tested Log4j 2 rather I havent used it anytime.
>>>>> I have been long working with log4j but off late we want to move to
>>>>> abstract logging frameworks  and precisely native SLF4J hence shifted
to
>>>>> Logback but I see fewer solutions for problems and  less crowd sourcing
>>>>> .Nonetheless looking at the log4j2 features and developments I am
>>>>> fascinated to use it with new features which we need but we are not willing
>>>>> to head because its still in beta . We are so hardly pressed with time
that
>>>>> we have no time for experimentation with frameworks since we are already
>>>>> lagging the deadline for our beta.
>>>>>
>>>>> Now you have to suggest with your best experience that how
>>>>> safe/efficient is using beta versions. Looking at the current usage of
>>>>> log4j2 and your rapid beta releases I feel you guys are on right track
and
>>>>> you should be able to make it :-)
>>>>>
>>>>> I am very positive on log4j2 and hoping to see the stable release. I
>>>>> will also definitely find some time and test log4j2.
>>>>>
>>>>> Thank you
>>>>> -Sudharma
>>>>>
>>>>>
>>>>> On Sun, Jul 14, 2013 at 12:48 PM, Ralph Goers <
>>>>> ralph.goers@dslextreme.com> wrote:
>>>>>
>>>>>> We have been trying to do releases about once a month. With each
new
>>>>>> release it is reasonable to ask if the next release should be 2.0
or
>>>>>> another beta. Have you been testing Log4j 2 and do you consider it
to be of
>>>>>> GA quality?
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jul 13, 2013, at 10:15 PM, Sudharma Puranik wrote:
>>>>>>
>>>>>> Hello Team,
>>>>>>
>>>>>> with the new beta release of log4j2 , I would like to know if there
>>>>>> is going to be a stable release of log4j2 this year anytime?. We
are
>>>>>> planning to migrate from logback to log4j2.
>>>>>>
>>>>>> I had posted about the release date on SO
>>>>>>
>>>>>>
>>>>>> http://stackoverflow.com/questions/17627672/stable-release-date-for-log4j2
>>>>>>
>>>>>> Could you please let me know what is the planned date for this
>>>>>> release
>>>>>>
>>>>>>
>>>>>> -Sudharma
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>

Mime
View raw message