<dependency>
<groupId>org.xerial<\/groupId>
<artifactId>sqlite-jdbc<\/artifactId>
<version>3.7.2<\/version>
<\/dependency><\/p>\n<\/blockquote>\n
Unfortunately, Tomcat did not have a Sqllite library available to it, so I included the Sqlite library in the WEB-INF\\lib folder, which is part of the classpath for Tomcat applications. <\/p>\n
During the build, Maven packaged up the JAR into the WAR file and, after deployment, the redistribution libraries are extracted to the app\u2019s \/lib folder under Tomcat:<\/p>\n
Practically done, I thought. But hold the celebration: Opening the database from the Java servlet is a more challenging problem. <\/p>\n (Typical of Java, easy things are harder than they should be and should-be-easy things are a nightmare.)<\/p>\n The root issue at this point is finding the Sqlite database on the Tomcat server. What should the file system path be in the connection string? On a foreign server, like the one my team will be using for our project, who can say where on disk the application and its resources will be?<\/p>\n The database location is obviously relative to the application, so the problem seemed surmountable. .NET has simple mechanisms for an application to determine where it is running; Java less so. One of the answers to a Stack Overflow question on the subject<\/a> helped me. The accepted answer is of no help since we can\u2019t count on a database file being deployed on the server, but MattC\u2019s answer was more useful: Use JNDI to read a configuration file and explode a Tomcat-relative path.<\/p>\n Following Matt\u2019s advice seemed easy. First, add a META-INF\/context.xml:<\/p>\n <?xml version="1.0" encoding="UTF-8"?> Second, add a resource reference to the WEB-INF\/web.xml:<\/p>\n <resource-ref> Third, use a JNDI context to look up the resource path and resolve the Tomcat root path macro by changing<\/p>\n c = DriverManager.getConnection("jdbc:sqlite:.\/test.db");<\/p>\n<\/blockquote>\n to<\/p>\n Context ctx = new InitialContext(); No problem.<\/p>\n That is, of course, where the problems began. After making these changes, Maven was unable to build the project because the javax.naming<\/em> library was not available to supply the JNDI classes. Maven didn\u2019t have it either<\/a>, meaning I had to download it from Oracle manually and add it to the project\u2019s local Maven repository. <\/p>\n This is yet another story, the short version of which is that I ended up with a C:\\Deve\\CS6440\\sqlwebexample\\lib\\javax\\naming\\jndi\\1.2.1\\jndi-1.2.1.jar file referenced by Maven.<\/p>\n (This is also how I referenced the Microsoft SQL Server JDBC driver in yet another story, so the technique definitely has its time in the sun.)<\/p>\n With JNDI in place Maven built the WAR file and for a moment my confidence was high. But I was quickly brought down to earth by this run-time exception:<\/p>\n ClassNotFoundException: org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory\u2026<\/p>\n<\/blockquote>\n![\"image\"](\"https:\/\/mooredynasty.net\/wp-content\/uploads\/2015\/02\/image.png\" "\\"image\\"")
<\/a><\/p>\n\n
<Context>
<Resource name="jdbc\/testdb"
auth="Container"
type="javax.sql.DataSource"
driverClassName="org.sqlite.JDBC"
url="jdbc:sqlite:${catalina.base}\/webapps\/sqlwebexample\/WEB-INF\/db\/test.db"
factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory">
<\/Resource>
<\/Context><\/p>\n<\/blockquote>\n\n
<description>CompanyDatabase<\/description>
<res-ref-name>jdbc\/testdb<\/res-ref-name>
<res-type>javax.sql.DataSource<\/res-type>
<res-auth>Container<\/res-auth>
<\/resource-ref><\/p>\n<\/blockquote>\n\n
\n
DataSource ds = (DataSource)ctx.lookup("java:comp\/env\/jdbc\/testdb");
c = ds.getConnection();<\/p>\n<\/blockquote>\n\n