Chad,
Agreed, putting it in the lib/ directory does provide more flexibility. However, it can cause crazy results due to altering the classpath. You could get really crazy and allow the Controller Service to take a path to the JDBC driver and then create your own classloader within there, but I wouldn’t recommend it, because the configuration is really weird then. The operator has to know about JDBC jars - and remember, the operator should NOT be assumed to be a developer. Often, operators are not developers, so I think expecting them to understand how to configure that is a bit odd. I think the ideal approach is to provide a NAR registry that people could provide their NARs to. We could then have a mysql connection pool, a postgres pool, etc., etc., as different NARs. This allows admins to choose what they want in their NiFi instance and avoid the bloat. However, building that registry is a very large undertaking, so it’s not really a viable solution for short term. Depending on how large the nar would be, i’d recommend just putting the drivers we want to support in the nar for now. Another possible solution would be to go ahead and create separate nars for each vendor, but not include them all in the build. Rather, we would release it but not include it in the assembly. Instructions could then be provided that point admins to the locations to pull the NARs. Anyone else have thoughts on how to set this up? Thanks -Mark From: Chad Zobrisky Sent: Tuesday, February 24, 2015 12:52 PM To: [email protected] 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. >
