You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2013/09/21 17:19:45 UTC
[ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
The Apache Log4j 2 team is pleased to announce the Log4j 2.0-beta9 release!
Apache log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to
Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides
many of the improvements available in Logback while fixing some inherent problems in Logback's
architecture.
This is the eleventh release of Log4j 2 and is being made available to encourage use and feedback from the community.
Bug fixes and enhancements
Changes in this version include:
New features:
o LOG4J2-399: Allow the default file rollover strategy to define the compression level.
o LOG4J2-338: Add TLSAppender. Also added missing license headers to several files. Thanks to Tibor Benke.
o LOG4J2-253: Added FAQ page to the site.
o LOG4J2-362: Add a diagram to the site (FAQ page) that explains when to use which jar.
o LOG4J2-374: Add more options to PatternLayout to display more detailed information about a Throwable. Thanks to Tibor Benke.
o LOG4J2-383: [Pattern Layout] Customize level names by length.
o LOG4J2-384: [Pattern Layout] Customize level names to lower-case.
o LOG4J2-364: Add WebLookup to retrieve information from the ServletContext. Thanks to David Nault.
o LOG4J2-360: Allow Plugins to have aliases.
o LOG4J2-356: Create a JSON Layout.
o LOG4J2-341: Enable XInclude for XML configurations.
o LOG4J2-313: Add JNDILookup plugin. Thanks to Woonsan Ko.
o LOG4J2-305: Ease porting from 1.x Logger.getRootLogger(): add LogManager.getRootLogger().
Fixed Bugs:
o LOG4J2-226: Fix table of contents generation in pdf.
o LOG4J2-395: Allow classpath scheme when specifying configuration file location as a system property. Thanks to Abhinav Shah.
o LOG4J2-393: Initialize PluginManager once during configuration. Move advertisement setup into BaseConfiguration.
o LOG4J2-391: FlumePersistentManager now handles LockConflictExceptions in Berkeley Db. Thanks to Kamal Bahadur.
o LOG4J2-380: Use rollover date when substituting ${date} in the filePattern.
o LOG4J2-322: Centralized reflective use of Reflection#getCallerClass and properly handled its instability in various versions
of Java.
o LOG4J2-293: Reset the Configuration if the ClassLoaderContextSelector creates a LoggerContext without a configuration
location and then is later provided one.
o LOG4J2-293: Changed the ConfigurationFactory to recognize and properly use the classpath: URI scheme in addition to the
classloader: URI scheme. Thanks to Abhinav Shah.
o LOG4J2-359: Changed the Servlet 3.0 auto-initializer so that it does nothing in a Servlet 2.5 or older application. This
ensures behavioral consistency across containers. Thanks to Abhinav Shah.
o LOG4J2-310: Fixed issue where SMTPAppender did not send mails with error or fatal level without prior info event. Thanks to Olivier Lemasle.
o LOG4J2-368: Add PatternLayout constructor to Log4j 1.2 bridge for Velocity.
o LOG4J2-333: Match artifact ids with Maven module names. Thanks to Hervé Boutemy.
o LOG4J2-367: JMS appenders send two messages for one append. Thanks to David Parry.
o LOG4J2-319: Double stack trace logging when using %throwable in %style and %highlight.
o LOG4J2-358: NoSQLAppender using MongoDB provider ignores username and password attributes
o LOG4J2-343: Removed unnecessary generics from Appender interface and implementing classes. Thanks to Henning Schmiedehausen.
o LOG4J2-351: [OSGi] wrong Fragment-Host in manifest files. Thanks to Roland Weiglhofer.
o LOG4J2-336: AsyncLogger errors after multiple calls to LoggerContext.reconfigure(). Thanks to Andre Bogus.
o LOG4J2-347: Give the AsyncAppender thread a more descriptive name for easier debugging/profiling. Thanks to David Phillips.
o LOG4J2-332: Modified documentation to refer to SLF4J Binding instead of SLF4J Bridge. Thanks to Hervé Boutemy.
o LOG4J2-342: Ignore xml:base attributes.
o LOG4J2-309: Insure jars and distributions only have a single License and Notice file.
o LOG4J2-320: JPAAppender stops logging because META-INF/log4j-provider.properties is left open.
o LOG4J2-335: FlumePersistentManager's writer thread had high CPU usage.
o LOG4J2-331: Removed erroneous check for affected MongoDB records, which always returns zero on inserts.
o LOG4J2-330: Added a BSON Transformer so that MongoDB can persist Log4j events.
o LOG4J2-329: StatusLogger now only creates StatusData objects if they are the appropriate logging level.
o LOG4J2-328: FlumePersistentManager was calling Berkeley DB's count method too frequently.
o LOG4J2-280: Additional fix to make AsyncAppender threads daemon threads and improve their thread name.
o LOG4J2-165: The slf4j-ext jar is now an optional dependency of the SLF4J bridge.
o LOG4J2-166: RoutingAppender's default Route can now be an appender reference.
o LOG4J2-299: Add getThrowable method to ThrowableProxy.
o LOG4J2-216: ThrowableProxy no longer extends Throwable.
o LOG4J2-311: Synchronized flush() and close() methods in the XxxFileManager and OutputStreamManager classes.
o LOG4J2-304: Fixed Async Loggers memory leak.
o LOG4J2-291: Fixed JDBC, JPA, and NoSQL appenders so that the failover appender properly fails over on error.
o LOG4J2-397: Logger.info(Message) Javadoc is incorrect. Thanks to Yonatan Graber.
Changes:
o LOG4J2-317: Renamed FastFileAppender and FastRollingFileAppender to RandomAccessFileAppender
and RollingRandomAccessFileAppender. Configurations using the Fast(Rolling)File element
no longer work and should be modified to use the (Rolling)RandomAccessFile element.
o Changed the "suppressExceptions" configuration attribute for all Appenders to "ignoreExceptions" to avoid
confusion with Java 7 suppressed exceptions. Also renamed the Appender#isExceptionSuppressed() method to
Appender#ignoreExceptions() to avoid the same confusion. All Appenders by default internally log and then ignore
exceptions encountered while logging. Setting "ignoreExceptions" to "false" on an Appender causes it to allow
exceptions to propagate to the caller. You must set "ignoreExceptions" to "false" for Appenders you are wrapping
in the Failover Appender.
o Changed the (relatively new) PatternLayout configuration attribute "suppressExceptions" to
"alwaysWriteExceptions" to more correctly indicate what it does. As such, the meaning of this attribute has
reversed (previous "true"s should become "false"s, and vice versa). Since this was an undocumented attribute up
until now, it's unlikely this change will affect any users.
o LOG4J2-355: Add support for multiple SD-ELEMENTs in a RFC 5424 syslog message. Thanks to Tibor Benke.
o Cleaned up tests and cleared up documentation for the JPA appender following the resolution of EclipseLink
issue #412454.
o LOG4J2-318: Allow shutdown hook to be disabled in the configuration.
o LOG4J2-312: XML layout improvements (compact vs. pretty, namespace, namespace prefix, root element).
o LOG4J2-388: Update Java Mail dependency to 1.5.0 from 1.4.7.
o LOG4J2-325: Update JDBC tests to use H2 database 1.3.173 from 1.3.172.
o LOG4J2-366: Update commons-logging to 1.1.3 from 1.1.1.
o LOG4J2-390: Update HSQLDB dependency to 2.3.0 from 2.2.9.
o LOG4J2-308: Clarified which library versions were used in Async Loggers performance test.
o LOG4J2-307: Updated Async Loggers' LMAX Disruptor library from 3.0.1 to 3.2.0.
o LOG4J2-306: Update JSON Jackson library to 2.2.2 from 2.2.1.
o LOG4J2-387: Update Jackson dependency to 1.9.13 from 1.9.11.
o Improved site by adding quick jump-off page and menu for Javadoc links for all components.
Apache Log4j 2.0-beta9 requires a minimum of Java 6 to build and run. Basic compatibility with
Log4j 1.x is provided through the log4j-1.2-api component, however it does not implement some of the
very implementation specific classes and methods. The package names and Maven groupId have been changed to
org.apache.logging.log4j to avoid any conflicts with log4j 1.x.
For complete information on Apache Log4j 2, including instructions on how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Log4j 2 website:
http://logging.apache.org/log4j/2.x/
Re: [ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
Posted by Roland <wg...@ids.de>.
You can define the version of the host to which the fragment has to bind to.
So you can have different versions in the osgi container without any
conflicts.
--
View this message in context: http://apache-logging.6191.n7.nabble.com/ANNOUNCEMENT-Apache-Log4j-2-0-beta9-released-tp40819p40918.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
Posted by Gary Gregory <ga...@gmail.com>.
All this hotness is cute but for log4j I predict nothing but trouble
if you try and mix versions of different log4j bundles. I can't
imagine trying to support anything but a simple "use the same version
for all log4j bundles" scenario.
Gary
On Sep 27, 2013, at 3:53, Roland <wg...@ids.de> wrote:
> Hi Gary,
> It is best practise to provide an implementation within a separate bundle
> whereas the interface is provided by an other bundle. You can update or
> replace the implementation at runtime without stopping the interface bundle.
> This is called "hot update". But there are some reasons why an
> implementation should be in the same bundle as the interface. For instance
> if the "interface" needs to know which implementation is installed (e.g. if
> you have to register some implementations to a proxy). In this case the
> implementation has to be in the classpath of the interface bundle. The
> interface can "see" the implementations if the packages are imported by the
> bundle (BTW this is bad practise, because an interface should not know
> anything about implementations and should not import them! This problem is
> often solved with reflection.). But what about non java resources like some
> settings or reflection files? They can not be imported. We can achieve this
> with fragmented bundles. All resources of a fragment are in the classpath of
> the host bundle at startup time. You do not need to parse resources within
> bundles within subdirectories, which is very time consuming because you
> have to install and start all bundles before you can access them. With
> fragmented bundles they are just there.
>
> Regards
> Roland
>
>
> Gary Gregory-4 wrote
>> [...]
>> It's not clear to me that we have the OSGi architecture settles with the
>> use of bundle fragments instead of plain bundles. It would be nice to have
>> an explanation of what our options are...
>> [...]
>
>
>
>
>
> --
> View this message in context: http://apache-logging.6191.n7.nabble.com/ANNOUNCEMENT-Apache-Log4j-2-0-beta9-released-tp40819p40910.html
> Sent from the Log4j - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
Posted by Roland <wg...@ids.de>.
Hi Gary,
It is best practise to provide an implementation within a separate bundle
whereas the interface is provided by an other bundle. You can update or
replace the implementation at runtime without stopping the interface bundle.
This is called "hot update". But there are some reasons why an
implementation should be in the same bundle as the interface. For instance
if the "interface" needs to know which implementation is installed (e.g. if
you have to register some implementations to a proxy). In this case the
implementation has to be in the classpath of the interface bundle. The
interface can "see" the implementations if the packages are imported by the
bundle (BTW this is bad practise, because an interface should not know
anything about implementations and should not import them! This problem is
often solved with reflection.). But what about non java resources like some
settings or reflection files? They can not be imported. We can achieve this
with fragmented bundles. All resources of a fragment are in the classpath of
the host bundle at startup time. You do not need to parse resources within
bundles within subdirectories, which is very time consuming because you
have to install and start all bundles before you can access them. With
fragmented bundles they are just there.
Regards
Roland
Gary Gregory-4 wrote
> [...]
> It's not clear to me that we have the OSGi architecture settles with the
> use of bundle fragments instead of plain bundles. It would be nice to have
> an explanation of what our options are...
> [...]
--
View this message in context: http://apache-logging.6191.n7.nabble.com/ANNOUNCEMENT-Apache-Log4j-2-0-beta9-released-tp40819p40910.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Sep 26, 2013 at 10:01 AM, Roland <wg...@ids.de> wrote:
> hello Ralph,
> ...and what about the classloader and package export issues in OSGi
> containers? Is there a schedule for a fix?
>
The idea is that we cleared the decks of a _lot_ of bug fixes and some
features for beta9. Now that we've made those improvements available, we
can keep on working on other fixes like OSGi.
It's not clear to me that we have the OSGi architecture settles with the
use of bundle fragments instead of plain bundles. It would be nice to have
an explanation of what our options are...
Gary
> Regards
> Roland.
>
>
>
> --
> View this message in context:
> http://apache-logging.6191.n7.nabble.com/ANNOUNCEMENT-Apache-Log4j-2-0-beta9-released-tp40819p40901.html
> Sent from the Log4j - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
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: [ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
Posted by Roland <wg...@ids.de>.
hello Ralph,
...and what about the classloader and package export issues in OSGi
containers? Is there a schedule for a fix?
Regards
Roland.
--
View this message in context: http://apache-logging.6191.n7.nabble.com/ANNOUNCEMENT-Apache-Log4j-2-0-beta9-released-tp40819p40901.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: [ANNOUNCEMENT] Apache Log4j 2.0-beta9 released
Posted by Christian Grobmeier <gr...@gmail.com>.
Ignore my last message - it made it through.
Thanks!
Ralph Goers schrieb:
> The Apache Log4j 2 team is pleased to announce the Log4j 2.0-beta9 release!
>
> Apache log4j is a well known framework for logging application behavior. Log4j 2 is an upgrade to
> Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides
> many of the improvements available in Logback while fixing some inherent problems in Logback's
> architecture.
>
> This is the eleventh release of Log4j 2 and is being made available to encourage use and feedback from the community.
>
> Bug fixes and enhancements
>
> Changes in this version include:
>
> New features:
> o LOG4J2-399: Allow the default file rollover strategy to define the compression level.
> o LOG4J2-338: Add TLSAppender. Also added missing license headers to several files. Thanks to Tibor Benke.
> o LOG4J2-253: Added FAQ page to the site.
> o LOG4J2-362: Add a diagram to the site (FAQ page) that explains when to use which jar.
> o LOG4J2-374: Add more options to PatternLayout to display more detailed information about a Throwable. Thanks to Tibor Benke.
> o LOG4J2-383: [Pattern Layout] Customize level names by length.
> o LOG4J2-384: [Pattern Layout] Customize level names to lower-case.
> o LOG4J2-364: Add WebLookup to retrieve information from the ServletContext. Thanks to David Nault.
> o LOG4J2-360: Allow Plugins to have aliases.
> o LOG4J2-356: Create a JSON Layout.
> o LOG4J2-341: Enable XInclude for XML configurations.
> o LOG4J2-313: Add JNDILookup plugin. Thanks to Woonsan Ko.
> o LOG4J2-305: Ease porting from 1.x Logger.getRootLogger(): add LogManager.getRootLogger().
>
> Fixed Bugs:
> o LOG4J2-226: Fix table of contents generation in pdf.
> o LOG4J2-395: Allow classpath scheme when specifying configuration file location as a system property. Thanks to Abhinav Shah.
> o LOG4J2-393: Initialize PluginManager once during configuration. Move advertisement setup into BaseConfiguration.
> o LOG4J2-391: FlumePersistentManager now handles LockConflictExceptions in Berkeley Db. Thanks to Kamal Bahadur.
> o LOG4J2-380: Use rollover date when substituting ${date} in the filePattern.
> o LOG4J2-322: Centralized reflective use of Reflection#getCallerClass and properly handled its instability in various versions
> of Java.
> o LOG4J2-293: Reset the Configuration if the ClassLoaderContextSelector creates a LoggerContext without a configuration
> location and then is later provided one.
> o LOG4J2-293: Changed the ConfigurationFactory to recognize and properly use the classpath: URI scheme in addition to the
> classloader: URI scheme. Thanks to Abhinav Shah.
> o LOG4J2-359: Changed the Servlet 3.0 auto-initializer so that it does nothing in a Servlet 2.5 or older application. This
> ensures behavioral consistency across containers. Thanks to Abhinav Shah.
> o LOG4J2-310: Fixed issue where SMTPAppender did not send mails with error or fatal level without prior info event. Thanks to Olivier Lemasle.
> o LOG4J2-368: Add PatternLayout constructor to Log4j 1.2 bridge for Velocity.
> o LOG4J2-333: Match artifact ids with Maven module names. Thanks to Hervé Boutemy.
> o LOG4J2-367: JMS appenders send two messages for one append. Thanks to David Parry.
> o LOG4J2-319: Double stack trace logging when using %throwable in %style and %highlight.
> o LOG4J2-358: NoSQLAppender using MongoDB provider ignores username and password attributes
> o LOG4J2-343: Removed unnecessary generics from Appender interface and implementing classes. Thanks to Henning Schmiedehausen.
> o LOG4J2-351: [OSGi] wrong Fragment-Host in manifest files. Thanks to Roland Weiglhofer.
> o LOG4J2-336: AsyncLogger errors after multiple calls to LoggerContext.reconfigure(). Thanks to Andre Bogus.
> o LOG4J2-347: Give the AsyncAppender thread a more descriptive name for easier debugging/profiling. Thanks to David Phillips.
> o LOG4J2-332: Modified documentation to refer to SLF4J Binding instead of SLF4J Bridge. Thanks to Hervé Boutemy.
> o LOG4J2-342: Ignore xml:base attributes.
> o LOG4J2-309: Insure jars and distributions only have a single License and Notice file.
> o LOG4J2-320: JPAAppender stops logging because META-INF/log4j-provider.properties is left open.
> o LOG4J2-335: FlumePersistentManager's writer thread had high CPU usage.
> o LOG4J2-331: Removed erroneous check for affected MongoDB records, which always returns zero on inserts.
> o LOG4J2-330: Added a BSON Transformer so that MongoDB can persist Log4j events.
> o LOG4J2-329: StatusLogger now only creates StatusData objects if they are the appropriate logging level.
> o LOG4J2-328: FlumePersistentManager was calling Berkeley DB's count method too frequently.
> o LOG4J2-280: Additional fix to make AsyncAppender threads daemon threads and improve their thread name.
> o LOG4J2-165: The slf4j-ext jar is now an optional dependency of the SLF4J bridge.
> o LOG4J2-166: RoutingAppender's default Route can now be an appender reference.
> o LOG4J2-299: Add getThrowable method to ThrowableProxy.
> o LOG4J2-216: ThrowableProxy no longer extends Throwable.
> o LOG4J2-311: Synchronized flush() and close() methods in the XxxFileManager and OutputStreamManager classes.
> o LOG4J2-304: Fixed Async Loggers memory leak.
> o LOG4J2-291: Fixed JDBC, JPA, and NoSQL appenders so that the failover appender properly fails over on error.
> o LOG4J2-397: Logger.info(Message) Javadoc is incorrect. Thanks to Yonatan Graber.
>
> Changes:
> o LOG4J2-317: Renamed FastFileAppender and FastRollingFileAppender to RandomAccessFileAppender
> and RollingRandomAccessFileAppender. Configurations using the Fast(Rolling)File element
> no longer work and should be modified to use the (Rolling)RandomAccessFile element.
> o Changed the "suppressExceptions" configuration attribute for all Appenders to "ignoreExceptions" to avoid
> confusion with Java 7 suppressed exceptions. Also renamed the Appender#isExceptionSuppressed() method to
> Appender#ignoreExceptions() to avoid the same confusion. All Appenders by default internally log and then ignore
> exceptions encountered while logging. Setting "ignoreExceptions" to "false" on an Appender causes it to allow
> exceptions to propagate to the caller. You must set "ignoreExceptions" to "false" for Appenders you are wrapping
> in the Failover Appender.
> o Changed the (relatively new) PatternLayout configuration attribute "suppressExceptions" to
> "alwaysWriteExceptions" to more correctly indicate what it does. As such, the meaning of this attribute has
> reversed (previous "true"s should become "false"s, and vice versa). Since this was an undocumented attribute up
> until now, it's unlikely this change will affect any users.
> o LOG4J2-355: Add support for multiple SD-ELEMENTs in a RFC 5424 syslog message. Thanks to Tibor Benke.
> o Cleaned up tests and cleared up documentation for the JPA appender following the resolution of EclipseLink
> issue #412454.
> o LOG4J2-318: Allow shutdown hook to be disabled in the configuration.
> o LOG4J2-312: XML layout improvements (compact vs. pretty, namespace, namespace prefix, root element).
> o LOG4J2-388: Update Java Mail dependency to 1.5.0 from 1.4.7.
> o LOG4J2-325: Update JDBC tests to use H2 database 1.3.173 from 1.3.172.
> o LOG4J2-366: Update commons-logging to 1.1.3 from 1.1.1.
> o LOG4J2-390: Update HSQLDB dependency to 2.3.0 from 2.2.9.
> o LOG4J2-308: Clarified which library versions were used in Async Loggers performance test.
> o LOG4J2-307: Updated Async Loggers' LMAX Disruptor library from 3.0.1 to 3.2.0.
> o LOG4J2-306: Update JSON Jackson library to 2.2.2 from 2.2.1.
> o LOG4J2-387: Update Jackson dependency to 1.9.13 from 1.9.11.
> o Improved site by adding quick jump-off page and menu for Javadoc links for all components.
>
>
> Apache Log4j 2.0-beta9 requires a minimum of Java 6 to build and run. Basic compatibility with
> Log4j 1.x is provided through the log4j-1.2-api component, however it does not implement some of the
> very implementation specific classes and methods. The package names and Maven groupId have been changed to
> org.apache.logging.log4j to avoid any conflicts with log4j 1.x.
>
> For complete information on Apache Log4j 2, including instructions on how to submit bug reports,
> patches, or suggestions for improvement, see the Apache Apache Log4j 2 website:
>
> http://logging.apache.org/log4j/2.x/
>
>