On Thu, Apr 25, 2013 at 11:37 AM, Nicholas Williams < nicho...@nicholaswilliams.net> wrote:
> > On Thu, Apr 25, 2013 at 10:01 AM, Remko Popma <rem...@yahoo.com> wrote: > >> I think this is the link Gary is talking about: (from the wiki) >> Build a NoSQL Appender, maybe with >> AppScale<http://wiki.apache.org/logging/AppScale> >> : http://appscale.cs.ucsb.edu/datastores.html Inspiration came from the >> log4j1 appender for redis: https://github.com/pavlobaron/log4j2redis >> >> > Unless I'm misunderstanding something (very possible), AppScale seems like > a lot of overhead and overkill. However, it should certainly be possible to > create a NoSqlAppender that has a "type" property where you specify the > database type (Mongo, Redis, etc.). > > One thing we need to keep in mind is dependencies: appending to Mongo will > require the org.mongodb:mongo-java-driver artifact (and its dependencies), > Redis will require the redis.clients:jedis artifact (and its dependencies), > etc. So, as far as I see it, we have two options: > > A) Have one NoSqlAppender that initially supports MongoDB and can easily > be made to support other NoSQL databases, put it in the log4j-core > artifact, and mark all dependencies as OPTIONAL or PROVIDED (thoughts? > opinions?) so as not to cause using projects to download unnecessary > dependencies. > > B) Put NoSQL appenders in separate artifacts so that dependencies don't > have to be optional/provided, but as a result each NoSQL will have to have > its own appender and each will result in a separate log4j artifact. > > I REALLY don't like option B, but optional/provided dependencies also > require careful, explicit documentation and, my bet, end up with lots of > mailing list emails "Why am I getting a NoClassDefError?". > That's not an issue IMO since you only get the error when the NoSQL appender class would be loaded. If you use plain log4j, you'd never see the error. If we do a NoSQL appender, it seems to me that each will have it's own idiosyncrasies and configuration tweak, so a single generic class is not going to be pretty so I would do: - an AppScale appender or equivalent JDBC-like vendor neutral API - If need be our own, with a NoSQL abstract appender and vendor specific subclasses. Gary > Agree with Gary on keeping things simple. Also agree every new feature >> needs to be in beta for a while to shake out bugs etc. I don't have an >> opinion on whether to include jdbc appenders in the first 2.0 release or >> add them later. >> >> You know, I was actually thinking to write a tutorial for custom plugin >> developers, called "(How to) Write Your Own Darn JdbcAppender!" :-) >> >> Sent from my iPhone >> >> On 2013/04/25, at 23:51, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> On Thu, Apr 25, 2013 at 10:39 AM, Nicholas Williams < >> nicho...@nicholaswilliams.net> wrote: >> >>> First, a quick question: do we anticipate the next version to be beta6 >>> or rc1? Just curious. >>> >> >> As long as we are adding features, I'd like to keep rolling Betas. But it >> would also be OK to release 2.0 and add appenders later. >> >> I tried porting our app to 2.0 a couple of weeks ago but ran into lots of >> issues, so I'll need to take another stab at it in a couple of weeks again. >> We rely on a lot of 1.0 guts so I'll have to think about that some more... >> >> >>> I'm currently working on cleaning up compiler warnings throughout the >>> project and should have that completed soon. >>> >> >> Great! >> >> >>> >>> I want to go ahead and get the conversation started about database >>> appenders. I'd like to see two appenders: >>> >>> - A JdbcAppender that is capable of logging to any RDBMS for which there >>> is a JDBC driver. >>> - A MongoAppender that is capable of logging to a MongoDB database. >>> >> >> We should not need a MongoDB appender if there is a JDBC driver for it: >> docs.mongodb.org/ecosystem/drivers/java/ >> >> >>> >>> The JdbcAppender and MongoAppender would, as far as I can tell, need >>> properties for mapping all of the possible logging event properties to >>> table columns (or Mongo equivalent). I don't really see any other way to >>> accomplish that. We could use layout patterns from the PatternLayout to >>> achieve this: <column name="columnName" pattern="PatternLayout >>> equivalent-pattern" /> >>> >> >> You can look at Log4J 1 for inspiration. Keep it simple for a start. I >> think version 1 just let's you specify a SQL INSERT instead of using some >> XML for mapping. >> >> >>> >>> I imagine the JdbcAppender having mutually exclusive properties for JDBC >>> URL/username/password, DataSource JNDI URL, and class.staticFactoryMethod >>> for obtaining a DataSource. >>> >> >> Keep is simple for the first cut ;) >> >> >>> >>> The MongoAppender would similarly have mutually exclusive properties for >>> connection information and class.statucFactoryMethod for obtaining a Mongo >>> instance. >>> >>> I'd like to take a stab at these after I complete fixing compiler >>> warnings, and wanted to start getting feedback/ideas and also see if anyone >>> has use cases for other NoSQL appenders. >>> >> >> Search the ML for my note on NoSQL, it looks like there is a JDBC-like >> API for NoSQL DBs. >> >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@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 >> >> > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
