Pool de connexion Java sans JNDI?

Question

J'ai un pool de connexions pour accéder à une base de données MySQL à partir d'une servlet. Je reçois la source de données en utilisant un JNDI, qui est défini sur mon fichier META-INF/context.xml.

Tout fonctionne correctement, mais je dois placer le fichier JAR du pilote MySQL dans le dossier Tomcat/common/lib, au lieu de WEB-INF/lib; sinon, le JNDI ne fonctionnera pas (ClassNotFoundException: com.mysql.jdbc.Driver).

Existe-t-il un autre moyen d'obtenir la source de données, ce qui me permet de placer le fichier JAR dans WEB-INF/lib? Tous les exemples que j'ai trouvé sur Internet utilisent JNDI ...

(C'est une application assez simple, je préférerais vraiment ne pas avoir à importer 53 JAR d'un framework pour résoudre mon problème :)

Merci!

Answer 1

Alors que la plupart de ces réponses concernent des pools, je ne pense pas que ce soit votre question?

Je pense que la réponse la plus directe à votre question est simplement d'importer et d'utiliser l'implémentation DataSource fournie par votre pilote. Vous utilisez MySQL Connector/J? alors c'est MysqlDataSource.

Il existe des méthodes sur elle pour définir le nom d'utilisateur, mot de passe, etc.

Si vous n'avez pas besoin dans JNDI, alors vous ne devez pas le configurer dans JNDI via Tomcat. Vous pouvez garder le pot de pilote dans WEB-INF/lib, bien sûr. Si vous voulez regrouper autour de cette source de données, en effet, il suffit d'utiliser Commons DBCP et Pool.

Voici un exemple de création de votre propre modèle pooling DataSource out of a given DataSource.

Answer 2

Vous pouvez essayer ce que le soleil suggère déjà: Connection Pooling

Answer 3

Si vous ne souhaitez pas utiliser JNDI, alors vous ne pouvez pas utiliser le mécanisme de pool de connexion de Tomcat, vous aurez besoin d'incorporer un dans votre application, et cela signifie ajouter des bibliothèques tierces à votre fichier WAR. C'est l'un ou l'autre, le choix vous appartient.

Si vous décidez d'utiliser la troisième voie, je suggère d'utiliser Apache Commons DBCP (ce qui nécessite à son tour Apache Commons Pool).

Answer 4

Des applications simples grandissent. Les cadres peuvent sembler au départ exagérés, mais trop facilement, vous trouvez progressivement que vous réinventez les roues et la croissance de votre propre cadre.

Considérez la personne qui vient après vous ... ils vont sur Internet et recherchent une technique, la trouvent couramment utilisée, revenez à votre code et voilà! vous l'avez fait d'une manière différente.

Le code de cadre Java EE, les pilotes JDBC, tout devrait être dans votre environnement de serveur, pas besoin de l'inclure dans votre application. Ainsi, les frais généraux devraient être assez faibles. Cette approche est vraiment rentable lorsque vous développez plus d'applications.

Mordez la balle, gardez la créativité pour les problèmes non résolus.

Answer 5

Je suis tout à fait d'accord avec vous pour dire que la source de données devrait rester hors contexte.xml. Vous devrez le faire si vous voulez externaliser votre configuration. Nous avons traversé ce processus il n'y a pas longtemps. C'est assez facile. Je ne peux pas vous donner le code, mais je peux vous indiquer la bonne direction,

1. Vous devez définir des ressources <> dans votre propre configuration et trouver un moyen de l'analyser. Vous pouvez utiliser JAXP, Apache Digester. Je suis paresseux donc j'utilise Apache Commons Configuration.

2. La ressource <> est juste des paires nom-valeur. Vous devez les convertir en propriétés.

3. Vous pouvez faire une source de données comme celui-ci,

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

Un effet secondaire de faire est que vous pouvez désactiver JNDI (useNaming = « false ») pour faire serveur un peu plus léger.