[I posted this in LOG4J2-10 and I'll post it here, too, in case someone misses it.]
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 LOG4J2-10 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. Nick On May 14, 2013, at 1:57 PM, Ralph Goers wrote: > I created LOG4J2-10 as one of the first requirements I had for Log4j 2. OSGi > support is very important in some environments. In fact, it is an area that I > have wanted to explore in my own operational environment. As part of a side > project at work I found a product called Paremus Service Fabric [1] which is > essentially an OSGi service container. In discussing the product with the > folks at Paremus I mentioned my desire to have better OSGi support in Log4j 2 > and asked them if they could help since it at that time (and I think it is > still true) we had very little OSGi expertise on the Log4j 2 team. They told > me they would see what they could do. Well recently Tim Ward has started > taking a look at what we are doing. Tim works for Paremus and has been > recently working with the Hibernate team to help them achieve similar goals. > Tim is also a committer and PMC member on Apache Aries and is the co-author > of Enterprise OSGi in Action. > > I wanted to give Tim this introduction so that you will understand that I > asked for his help and am grateful that he has taken the time to lend us a > hand. As such I plan to look at the patches he provides from the perspective > of what would be best for our OSGi users. At the same time we also need to > not lose focus on what is best for our non-OSGi users. This may make the > build and release more complicated but I really think we need to make sure > the needs of both of these user sets are being met. > > Ralph > > > > > > [1] http://www.paremus.com > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
