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 "Dusa, Silviu" <Si...@federal.dell.com> on 2010/09/30 17:28:29 UTC

Log4J Future Releases Question

Hi,
 
My name is Silviu Dusa and I am an architect for a rather large organization. I am in charge with the assessment of Log4J for future development.
 
We perused the text found at the wiki site (http://wiki.apache.org/logging-log4j/) but it is not clear what the direction Log4J is going is. 
 
Specifically I would need answers to the following questions:
 
1. Version 1.2 is recommended for versions prior to Java 6 and Java 5, though it is compatible with them. What is the future of it? How long is it still going to be supported?
2. When is version 2.0 slated for release?
3. What is the future of 'logback'? When will it be released? Will it be a replacement for Log4J in the Apache technologies?
 
Thank you for your help.
 
Silviu Dusa
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Re: Log4J Future Releases Question

Posted by Ralph Goers <ra...@dslextreme.com>.
I would add that Logback is not an Apache project so it would be inappropriate for Log4j to discuss the future of Logback or what its release schedule is.  SLF4J is used by some Apache projects, which means that either Log4j or Logback can be integrated.  

Ralph

On Sep 30, 2010, at 1:04 PM, Scott Deboy wrote:

> The log4j 1.2 line will continue to be maintained.
> 
> Some work has gone into designing Log4j 2, but it is still in the early stages.
> 
> I'm not very familiar with the logback library, but each logging library has pros and cons relative to log4j.  
> 
> One of the main differences between log4j some some of the other libraries is that many logging libraries take a String argument in the logging methods, while log4j takes an Object.  In some scenarios, passing in a custom Object to logging methods allows custom filters, appenders and renderers to do some things that would be difficult with strings.
> 
> There is also the RepositorySelector feature available with log4j.  I'm not sure if other frameworks have something similar.
> 
> There was an attempt a long time ago to consolidate the API used by log4j and the logback library, but the Object/String issue seemed to prevent consensus.
> 
> Scott
> 
> On Thu, Sep 30, 2010 at 8:28 AM, Dusa, Silviu <Si...@federal.dell.com> wrote:
> Hi,
> 
> My name is Silviu Dusa and I am an architect for a rather large organization. I am in charge with the assessment of Log4J for future development.
> 
> We perused the text found at the wiki site (http://wiki.apache.org/logging-log4j/) but it is not clear what the direction Log4J is going is.
> 
> Specifically I would need answers to the following questions:
> 
> 1. Version 1.2 is recommended for versions prior to Java 6 and Java 5, though it is compatible with them. What is the future of it? How long is it still going to be supported?
> 2. When is version 2.0 slated for release?
> 3. What is the future of 'logback'? When will it be released? Will it be a replacement for Log4J in the Apache technologies?
> 
> Thank you for your help.
> 
> Silviu Dusa
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 


Re: Log4J Future Releases Question

Posted by Scott Deboy <sc...@gmail.com>.
The log4j 1.2 line will continue to be maintained.

Some work has gone into designing Log4j 2, but it is still in the early
stages.

I'm not very familiar with the logback library, but each logging library has
pros and cons relative to log4j.

One of the main differences between log4j some some of the other libraries
is that many logging libraries take a String argument in the logging
methods, while log4j takes an Object.  In some scenarios, passing in a
custom Object to logging methods allows custom filters, appenders and
renderers to do some things that would be difficult with strings.

There is also the RepositorySelector feature available with log4j.  I'm not
sure if other frameworks have something similar.

There was an attempt a long time ago to consolidate the API used by log4j
and the logback library, but the Object/String issue seemed to prevent
consensus.

Scott

On Thu, Sep 30, 2010 at 8:28 AM, Dusa, Silviu
<Si...@federal.dell.com>wrote:

> Hi,
>
> My name is Silviu Dusa and I am an architect for a rather large
> organization. I am in charge with the assessment of Log4J for future
> development.
>
> We perused the text found at the wiki site (
> http://wiki.apache.org/logging-log4j/) but it is not clear what the
> direction Log4J is going is.
>
> Specifically I would need answers to the following questions:
>
> 1. Version 1.2 is recommended for versions prior to Java 6 and Java 5,
> though it is compatible with them. What is the future of it? How long is it
> still going to be supported?
> 2. When is version 2.0 slated for release?
> 3. What is the future of 'logback'? When will it be released? Will it be a
> replacement for Log4J in the Apache technologies?
>
> Thank you for your help.
>
> Silviu Dusa
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>