开发者

Java connection pool without JNDI?

开发者 https://www.devze.com 2022-12-08 11:08 出处:网络
I\'ve a connection pool to access a MySQL DB from a servlet. I get the data source using a JNDI, which is defined on my META-INF/context.xml file.

I've a connection pool to access a MySQL DB from a servlet. I get the data source using a JNDI, which is defined on my META-INF/context.xml file.

Everything is working fine, but I have to place the MySQL driver JAR within Tomcat's /common/lib folder, instead of webapp's WEB-INF开发者_开发百科/lib; otherwise the JNDI will not work (ClassNotFoundException: com.mysql.jdbc.Driver).

Is there any other way to get the datasource, which allows me to place the JAR inside WEB-INF/lib? All the examples I've found over the Internet are using JNDI...

(It's a quite simple application, I'd really prefer not to have to import 53 JARs of some framework in order to solve my problem :)

Thanks!


While most of these replies are about pools, I don't think that's your question?

I think the most direct answer to your question is, simply import and use the DataSource implementation provided by your driver. You're using MySQL Connector/J? then it's MysqlDataSource.

There are methods on it to set username, password, etc.

If you don't need it in JNDI, then you don't have to configure it in JNDI via Tomcat. You can keep the driver jar in WEB-INF/lib, sure. If you want pooling around that DataSource, indeed, just use Commons DBCP and Pool.

Here's an example of making your own pooling DataSource out of a given DataSource.


You might try what sun already suggests: Connection Pooling


If you don't want to use JNDI, then you can't use Tomcat's connection pool mechanism, you'll need to incorporate one into your application, and that means adding 3rd-party libraries to your WAR file. It's one or the other, the choice is yours.

If you decide to go the 3rd-party route, I suggest using Apache Commons DBCP (which in turn requires Apache Commons Pool).


Simple apps grow. Frameworks may initially seem like overkill, but all too easily you gradually find that you are reinventing wheels and growing your own framework.

Consider the person who comes after you ... they go to the internet and look up a technique, find it commonly used, come back to your code and lo! you did it a different way.

The Java EE framework code, the JDBC drivers, everything should be in your server environment, no need to include it into your app. So the overhead should be quite small. This approach really pays off as you develop more applications.

Bite the bullet, save the creativity for the unsolved problems.


I definitely agree with you that datasource should stay out of context.xml. You will have to do this if you want externalize your configuration. We went through this process not long ago. It's quite easy. I can't give you the code but I can point you to the right direction,

  1. You need to define <Resource> in your own configuration and find a way to parse it. You can use JAXP, Apache Digester. I am lazy so I use Apache Commons Configuration.

  2. The <Resource> is just name-value pairs. You need to convert them into Properties.

  3. You can make a datasource like this,

    DataSource ds = org.apache.commons.dbcp.BasicDataSourceFactory.createDataSource(prop);

A side-effect of doing this is that you can disable JNDI (useNaming="false") to make server a little bit lighter.

0

精彩评论

暂无评论...
验证码 换一张
取 消