Mark - I agree. The current one I'm using it is built into the nar as a dependency, but this can be prohibitive.
The biggest advantage of putting it in the lib is what I believe Toivo is getting at. If someone wanted to connect to Postgres, all they would have to do is drop the postgres jdbc driver into the lib verse building or rebuilding the Database service package. Having the flexibility of dropping a jar in the lib directory is nice, but it does pollute the base of nifi. Maybe including some drivers in the nar, but still allowing a user the option to drop a driver in the lib directory would be a good choice? This makes it easy for the end user but also doesn't bloat the Database service with unused drivers. Just some thoughts. Chad On Tue, Feb 24, 2015 at 12:34 PM, Toivo Adams <[email protected]> wrote: > I'd like not to put JDBC driver jar files to nar because every database > vendor has it's own JDBC driver jar file. > This way service will work with any database which have JDBC compliant > driver. > > Don't know is NiFi lib right place for JDBC drivers, but at least this is > better than in nar file. > But when you can add your custom nar files to NiFi lib directory, then why > not JDBC jar's? > > > Thanks > toivo > > > > > -- > View this message in context: > http://apache-nifi-incubating-developer-list.39713.n7.nabble.com/New-Database-Connection-Pooling-Controller-Service-tp582p842.html > Sent from the Apache NiFi (incubating) Developer List mailing list archive > at Nabble.com. >
