Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Mon, 29 Apr 2013 22:08:15 +0000 (UTC)
From: "Nick Williams (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12645319.1367273184552.244560.1367273295755@arcas>
In-Reply-To: <JIRA.12645319.1367273184552@arcas>
References: <JIRA.12645319.1367273184552@arcas>
Subject: [jira] [Updated] (LOG4J2-229) New JDBC, JPA, and NoSQL Database
 Appenders for Log4j2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LOG4J2-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Williams updated LOG4J2-229:
---------------------------------

    Attachment: db-appenders.patch

Patch attached. Current as of 2013-04-29 16:50:00 -05:00.
                
> New JDBC, JPA, and NoSQL Database Appenders for Log4j2
> ------------------------------------------------------
>
>                 Key: LOG4J2-229
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-229
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Appenders, Core
>    Affects Versions: 2.0-beta5
>            Reporter: Nick Williams
>         Attachments: db-appenders.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> As discussed on the mailing list ([1] and [2]), Log4j 2 is in need of some database appenders. I have added this new feature and will attach a patch shortly. The patch contains:
> - A slight change to PatternLayout. Currently it is not possible to create a PatternLayout that doesn't always handle exceptions. If you leave all exception handling out of the pattern, an exception handler is forcibly added to the end of the pattern. This behavior is controlled by a flag, but that flag is always hard-coded to false. I added a parameter for it. This was necessary for the JDBC appender.
> - o.a.l.l.core.appender.db.AbstractDatabaseManager and AbstractDatabaseAppender, together in concert, take care of some core functionality common across all database appenders, such as buffering and connection state.
> - o.a.l.l.core.appender.db.jdbc.JDBCAppender (and Manager, other classes) supports writing events to a relational database using raw JDBC. It's injection-safe due to the use of prepared statements. It can be configured with URL/username/password, JNDI data source, or a connection factory method.
> - o.a.l.l.core.appender.db.jpa.JPAAppender (and Manager, other classes) supports writing events to a relational database using the Java Persistence API version 2.0.
> - o.a.l.l.core.appender.db.nosql.NoSQLAppender (and Manager, other classes) supports writing to an abstract concept of a NoSQL provider. Providers have been created for MongoDB and Apache CouchDB. Creating a new provider is extremely easy.
> - Thorough unit tests for the abstract classes, the JDBC and JPA appenders, and the abstract parts of the NoSQLAppender. Directly unit testing the MongoDB and CouchDB providers in a platform-independent way is not easy and may not be possible.
> - Thorough documentation (both JavaDoc and Site documentation) for all of the appenders.
> [1] http://markmail.org/thread/z2wpmwelv7p6xh2o
> [2] http://markmail.org/thread/s7pljqdjhjz5xfk5

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org