[
https://issues.apache.org/jira/browse/LOG4J2-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657529#comment-13657529
]
Nick Williams commented on LOG4J2-10:
-------------------------------------
First, I will prefix this with "I know nothing about OSGi." Of course, that's
kind of a lie, because I've been able to gleam from this and LOG4J2-238 and
discussions on the mailing list that OSGi is some kind of module system for
Java. That's all I know.
Second, I would like to *2 Gary's -1 (i.e., I would like to -1 splitting out
the Core into multiple JARs). There are so ... many ... JARs already.
As I have been the driver and developer of the database Appenders, and since
they have been specifically mentioned in these discussions, I will address them
and their needs here.
- Abstract Database Appender (o.a.l.l.core.appender.db): This serves as the
base Appender from which all existing database appenders are derived, and it
can also be custom-extended by Core users who want to do something different.
It depends only on JRE classes and other classes in the Core.
- JDBC Appender (o.a.l.l.core.appender.db.jdbc): This Appender is for writing
events to a relational (SQL) database using JDBC. The only "extra" dependency
it has is on the JDBC driver of the user's choice. If I were a betting man and
weren't poor, I'd bet bookoos of money that 100% of users of this Appender
/already/ are using JDBC for something else and /already/ have the driver on
their class path. Problem solved.
- JPA Appender (o.a.l.l.core.appender.db.jpa): This Appender is for writing
events to a relational (SQL) database using JPA 2.1. This has "extra"
dependencies of 1) The JPA 2.1 API, 2) The JPA provider of choice, 3) The JDBC
driver of choice. The JPA 2.1 API provider is the OSGi dependency that we can
export. The JPA provider and JDBC driver are completely up to the user. The
/only/ compelling reason to use the JPA Appender instead of the JDBC Appender
is if you are already using JPA; otherwise, it's a lot of extra work (read:
configuration) for no gain. Therefore, I believe the suggestion that users of
this Appender would struggle with NoClassDefFoundErrors if the JPA OSGi
dependency were optional is a non-starter. They will already have it on the
class path, along with their provider and JDBC driver.
- NoSQL Appender (o.a.l.l.core.appender.db.nosql): This Appender is for writing
events to a non-relational (NoSQL) database. There is no common API like JDBC
for using NoSQL databases, since they are all so different. Thus, this appender
has *no* extra dependencies; just the JRE and the Core. It specifies its own
common NoSQL API called the NoSQLProvider that specifies only the ability to
insert records, because that's all Log4j needs. Users who want to support a
currently-unsupported NoSQL database need only implement this simple provider
API; they don't have to know anything about Appenders.
- MongoDB NoSQL Provider (o.a.l.l.core.appender.db.nosql.mongo): This is a
MongoDB implementation of the aforementioned NoSQL Provider API. It depends on
the Mongo Java Driver supplied by MongoDB. Here is something that could be
interesting. I CAN think of two use cases where one might wish to use this
provider and not already have the Mongo Java Driver on their class path: 1) In
my case, for example, I will be using MongoDB /only/ for logging. I won't use
it for any other data storage, I'll be using JPA and MySQL for all my other
needs. 2) The Mongo Java Driver is not the only way to access MongoDB from
Java, so users might be using MongoDB without using the Mongo Java Driver.
There's not an easy answer to this. I still favor it being an optional OSGi
dependency with strong documentation.
- Apache CouchDB NoSQL Provider (o.a.l.l.core.appender.db.nosql.couch): Pretty
much ditto the MongoDB provider, but slightly worse. While the Mongo Java
Driver is /almost always/ the library of choice for Java users for MongoDB,
there are /many/ Java libraries for CouchDB. I had to pick the most popular and
"recommended" one: LightCouch. Therefore, the idea that the user may be using a
different CouchDB Java library is more likely. There's not an easy answer to
this. I still favor it being an optional OSGi dependency with strong
documentation.
> log4j 2.0 should work well with OSGi and Apache Felix
> -----------------------------------------------------
>
> Key: LOG4J2-10
> URL: https://issues.apache.org/jira/browse/LOG4J2-10
> Project: Log4j 2
> Issue Type: Wish
> Reporter: Curt Arnold
> Attachments: reduced-dependency-bundles.patch
>
>
> OSGi and specifically the Apache Felix implementation should be considered
> for framework services such as internal logging and configuration.
> log4j 2.0 should be able to be a provider of OSGi logging services.
> OSGi package visibility declarations should be used to distinguish between
> exported and explicitly supported APIs and implementation specific details.
--
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: [email protected]
For additional commands, e-mail: [email protected]
