JDBC et WebService

Bonjour Matt,

Je n'ai jamais eu l'occasion d'implémenter des Web Services via Metro...
mais, je ne vois pas pourquoi celà ne serait pas possible !

Avant tout (comme avec Axis2), Il te faut le connecteur mysql java à placer
dans un truc du genre .../webapps/metro/WEB- INF/lib/
Tu trouveras le jar mysql-connector-java.jar chez Oracle...
Note: le connecteur doit biensur être dans le classpath (à paramétrer sur
ton conteneur de servlet et/ou ton serveur d'application).
Meilleurs voeux
--
Philippe

Le Fri, 07 Jan 2011 19:48:12 +0100, Philippe <no@spam.fr> a écrit:

Bonjour Matt,

Je n'ai jamais eu l'occasion d'implémenter des Web Services via M etro...
mais, je ne vois pas pourquoi celà ne serait pas possible !

Avant tout (comme avec Axis2), Il te faut le connecteur mysql java à  
placer
dans un truc du genre .../webapps/metro/WEB- INF/lib/
Tu trouveras le jar mysql-connector-java.jar chez Oracle...
Note: le connecteur doit biensur être dans le classpath (à p aramétrer sur
ton conteneur de servlet et/ou ton serveur d'application).
Meilleurs voeux

Merci pour ta réponse,

J'ai fait une class pour me connecter à ma base et ça marche i mpeccable
dans une application "normale". Mais quand je l'utilise dans le
webservice, j'ai l'exception "ClassNoFound" quand je fais
Class.forName("com.mysql.jdbc.Driver");

Donc, cela serait mon conteneur qui ne voit pas le connecteur mysql ?
Pour le conteneur de servlet, j'ai apache TomCat.

Meilleurs voeux aussi,

matt...

--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/

C'est un problème d'exécution... ton jar n'est pas dans le classpath de ton
tomcat !

Comment déploies-tu ton appli ?

As-tu regardé le contenu "$CATALINA/webapps/metro/WEB- INF/lib"... tu dois y
trouver le connecteur mysql
De plus la variable $CLASSPATH devrait contenir le jar de mysql

$CATALINA = %CATALINA% sur windows


Question: pourquoi utiliser Metro et non pas Axis2 ? tu trouveras plus
facilement des tutos pour Axis... et il est même intégré à Netbeans !
--
Philippe

Le Sat, 08 Jan 2011 11:01:29 +0100, Philippe <no@spam.fr> a écrit:

C'est un problème d'exécution... ton jar n'est pas dans le c lasspath de
ton
tomcat !

Comment déploies-tu ton appli ?

As-tu regardé le contenu "$CATALINA/webapps/metro/WEB- INF/lib".. . tu
dois y
trouver le connecteur mysql
De plus la variable $CLASSPATH devrait contenir le jar de mysql

$CATALINA = %CATALINA% sur windows


Question: pourquoi utiliser Metro et non pas Axis2 ? tu trouveras plus
facilement des tutos pour Axis... et il est même intégré à Netbeans !

J'utilise Metro car c'est une contrainte du boulot...
Pour le déploiement, j'utilise un fichier build.xml et je l'exé cute avec
ANT.

Je regarde tout cela demain au boulot et je te tiens au courant.

merci,

matt...

--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/

Le 09/01/2011 10:15, Matt... a écrit :

Le Sat, 08 Jan 2011 11:01:29 +0100, Philippe <no@spam.fr> a écrit:

C'est un problème d'exécution... ton jar n'est pas dans le classpath
de ton
tomcat !

Comment déploies-tu ton appli ?

As-tu regardé le contenu "$CATALINA/webapps/metro/WEB- INF/lib"... tu
dois y
trouver le connecteur mysql
De plus la variable $CLASSPATH devrait contenir le jar de mysql

$CATALINA = %CATALINA% sur windows


Question: pourquoi utiliser Metro et non pas Axis2 ? tu trouveras plus
facilement des tutos pour Axis... et il est même intégré à Netbeans !

J'utilise Metro car c'est une contrainte du boulot...
Pour le déploiement, j'utilise un fichier build.xml et je l'exécute avec
ANT.

Je regarde tout cela demain au boulot et je te tiens au courant.

merci,

matt...

Et puis un autre conseil, pour les appels database, ne fais pas de
l'accès unitaire JDBC, si ton application a de nombreux utilisateurs,
utilise plutôt une datasource/Pool JDBC fournie par le container
Servlet/JSP. Par exemple pour Tomcat prend la datasource du pool JDBC =>
DBCP. Le container va résoudre l'accès à la database par un look-up JNDI
( mais tu n'as pas à t'en soucier, c'est le container qui fait cela, à
paramétrer cependant dans web.xml, context.xml).
Tout est expliqué là =>
http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

Le Sun, 09 Jan 2011 10:57:35 +0100, jlp <jlp@jlp.com> a écrit:

Le 09/01/2011 10:15, Matt... a écrit :

Le Sat, 08 Jan 2011 11:01:29 +0100, Philippe <no@spam.fr> a écri t:

C'est un problème d'exécution... ton jar n'est pas dans le classpath
de ton
tomcat !

Comment déploies-tu ton appli ?

As-tu regardé le contenu "$CATALINA/webapps/metro/WEB- INF/lib" ... tu
dois y
trouver le connecteur mysql
De plus la variable $CLASSPATH devrait contenir le jar de mysql

$CATALINA = %CATALINA% sur windows


Question: pourquoi utiliser Metro et non pas Axis2 ? tu trouveras pl us
facilement des tutos pour Axis... et il est même intégrà © à Netbeans !

J'utilise Metro car c'est une contrainte du boulot...
Pour le déploiement, j'utilise un fichier build.xml et je l'exà ©cute avec
ANT.

Je regarde tout cela demain au boulot et je te tiens au courant.

merci,

matt...

Et puis un autre conseil, pour les appels database, ne fais pas de
l'accès unitaire JDBC, si ton application a de nombreux utilisate urs,
utilise plutôt une datasource/Pool JDBC fournie par le container
Servlet/JSP. Par exemple pour Tomcat prend la datasource du pool JDBC =>
DBCP. Le container va résoudre l'accès à la database pa r un look-up JNDI
( mais tu n'as pas à t'en soucier, c'est le container qui fait ce la, à
paramétrer cependant dans web.xml, context.xml).
Tout est expliqué là =>
http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JDBC _Data_Sources

Je ne sais pas si cela est important mais les requêtes sur ma base pour
mon application ne sont que des "select".
Les "insert" étant fait pas une autre application. Par contre, il y a pas
mal de client qui requêtent (une centaine environ).

merci,

matt...

--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/

Le 09/01/2011 11:27, Matt... a écrit :

Le Sun, 09 Jan 2011 10:57:35 +0100, jlp <jlp@jlp.com> a écrit:

Le 09/01/2011 10:15, Matt... a écrit :

Le Sat, 08 Jan 2011 11:01:29 +0100, Philippe <no@spam.fr> a écrit:

C'est un problème d'exécution... ton jar n'est pas dans le classpath
de ton
tomcat !

Comment déploies-tu ton appli ?

As-tu regardé le contenu "$CATALINA/webapps/metro/WEB- INF/lib"... tu
dois y
trouver le connecteur mysql
De plus la variable $CLASSPATH devrait contenir le jar de mysql

$CATALINA = %CATALINA% sur windows


Question: pourquoi utiliser Metro et non pas Axis2 ? tu trouveras plus
facilement des tutos pour Axis... et il est même intégré à Netbeans !

J'utilise Metro car c'est une contrainte du boulot...
Pour le déploiement, j'utilise un fichier build.xml et je l'exécute avec
ANT.

Je regarde tout cela demain au boulot et je te tiens au courant.

merci,

matt...

Et puis un autre conseil, pour les appels database, ne fais pas de
l'accès unitaire JDBC, si ton application a de nombreux utilisateurs,
utilise plutôt une datasource/Pool JDBC fournie par le container
Servlet/JSP. Par exemple pour Tomcat prend la datasource du pool JDBC
=> DBCP. Le container va résoudre l'accès à la database par un look-up
JNDI ( mais tu n'as pas à t'en soucier, c'est le container qui fait
cela, à paramétrer cependant dans web.xml, context.xml).
Tout est expliqué là =>
http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

Je ne sais pas si cela est important mais les requêtes sur ma base pour
mon application ne sont que des "select".
Les "insert" étant fait pas une autre application. Par contre, il y a
pas mal de client qui requêtent (une centaine environ).

merci,

matt...

Peu importe le type de requête.
Ce qui es pénalisant pour une database c'est aussi la phase
connexion/deconnexion. L'utilisation d'une datasource et son pool de
connexions associé permet de limiter ces connexions/deconnexions. Il
faut pour cela définir dans ton pool JDBC une taille minimale et une
taille maximale de ton pool, en fonction respectivement du nombre
d'utilisateurs connectés en moyenne à la base ( pool mini) et du nombre
d'utilisateurs connectés au maximum ( pool maxi). Dans ton cas pool maxi
0, et tu peux commencer avec un pool mini% par exemple.
En deux mots le principe est le suivant :
- Un appel de de-connexion dans le code ( ds.disconnect()), ne
déconnecte pas obligatoirement la connexion à la base, il rend d'abord
la connexion au pool. et si le nombre de connexion mini est dépassé,
alors le pool déconnecte physiquement la connexion à la base.
- Une demande de connexion à la base va générer un appel de connexion
non occupée parmi les connexions établies du pool, il n'y a pas de
connexion physique puisqu'elle existe déjà( Bien sur si toutes les
connexions du pool sont occupées, on ouvre physiquement une autre
connexion).
Pour MysSQL, la requête showsql permet de suivre ( parmi les nombreux
paramètres renvoyés) le nombre de threads actifs ( cad les connexions à
la base). Voir avec ton DBA, il te donnera d'autres tips.
J'espère n'avoir pas été trop brouillon dans mes explications.

Le 09/01/2011 12:03, jlp a écrit :

Le 09/01/2011 11:27, Matt... a écrit :

Le Sun, 09 Jan 2011 10:57:35 +0100, jlp <jlp@jlp.com> a écrit:

Le 09/01/2011 10:15, Matt... a écrit :

Le Sat, 08 Jan 2011 11:01:29 +0100, Philippe <no@spam.fr> a écrit:

C'est un problème d'exécution... ton jar n'est pas dans le classpath
de ton
tomcat !

Comment déploies-tu ton appli ?

As-tu regardé le contenu "$CATALINA/webapps/metro/WEB- INF/lib"... tu
dois y
trouver le connecteur mysql
De plus la variable $CLASSPATH devrait contenir le jar de mysql

$CATALINA = %CATALINA% sur windows


Question: pourquoi utiliser Metro et non pas Axis2 ? tu trouveras plus
facilement des tutos pour Axis... et il est même intégré à Netbeans !

J'utilise Metro car c'est une contrainte du boulot...
Pour le déploiement, j'utilise un fichier build.xml et je l'exécute
avec
ANT.

Je regarde tout cela demain au boulot et je te tiens au courant.

merci,

matt...

Et puis un autre conseil, pour les appels database, ne fais pas de
l'accès unitaire JDBC, si ton application a de nombreux utilisateurs,
utilise plutôt une datasource/Pool JDBC fournie par le container
Servlet/JSP. Par exemple pour Tomcat prend la datasource du pool JDBC
=> DBCP. Le container va résoudre l'accès à la database par un look-up
JNDI ( mais tu n'as pas à t'en soucier, c'est le container qui fait
cela, à paramétrer cependant dans web.xml, context.xml).
Tout est expliqué là =>
http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

Je ne sais pas si cela est important mais les requêtes sur ma base pour
mon application ne sont que des "select".
Les "insert" étant fait pas une autre application. Par contre, il y a
pas mal de client qui requêtent (une centaine environ).

merci,

matt...

Peu importe le type de requête.
Ce qui es pénalisant pour une database c'est aussi la phase
connexion/deconnexion. L'utilisation d'une datasource et son pool de
connexions associé permet de limiter ces connexions/deconnexions. Il
faut pour cela définir dans ton pool JDBC une taille minimale et une
taille maximale de ton pool, en fonction respectivement du nombre
d'utilisateurs connectés en moyenne à la base ( pool mini) et du nombre
d'utilisateurs connectés au maximum ( pool maxi). Dans ton cas pool maxi
0, et tu peux commencer avec un pool mini% par exemple.
En deux mots le principe est le suivant :
- Un appel de de-connexion dans le code ( ds.disconnect()), ne
déconnecte pas obligatoirement la connexion à la base, il rend d'abord
la connexion au pool. et si le nombre de connexion mini est dépassé,
alors le pool déconnecte physiquement la connexion à la base.
- Une demande de connexion à la base va générer un appel de connexion
non occupée parmi les connexions établies du pool, il n'y a pas de
connexion physique puisqu'elle existe déjà( Bien sur si toutes les
connexions du pool sont occupées, on ouvre physiquement une autre
connexion).
Pour MysSQL, la requête showsql permet de suivre ( parmi les nombreux
paramètres renvoyés) le nombre de threads actifs ( cad les connexions à
la base). Voir avec ton DBA, il te donnera d'autres tips.
J'espère n'avoir pas été trop brouillon dans mes explications.

Autre conseil si tu le permets, tu n'utilises pas à priori un mapper
(ORM genre Hibernate, TopLink ou autre), pour tes requêtes utilises des
PreparedStatement à variables bindées

Le Sun, 09 Jan 2011 12:03:46 +0100, jlp <jlp@jlp.com> a écrit:

Le 09/01/2011 11:27, Matt... a écrit :

Le Sun, 09 Jan 2011 10:57:35 +0100, jlp <jlp@jlp.com> a écrit:

Le 09/01/2011 10:15, Matt... a écrit :

Le Sat, 08 Jan 2011 11:01:29 +0100, Philippe <no@spam.fr> a éc rit:

C'est un problème d'exécution... ton jar n'est pas dans le classpath
de ton
tomcat !

Comment déploies-tu ton appli ?

As-tu regardé le contenu "$CATALINA/webapps/metro/WEB- INF/li b"... tu
dois y
trouver le connecteur mysql
De plus la variable $CLASSPATH devrait contenir le jar de mysql

$CATALINA = %CATALINA% sur windows


Question: pourquoi utiliser Metro et non pas Axis2 ? tu trouveras
plus
facilement des tutos pour Axis... et il est même intégrà © à Netbeans !

J'utilise Metro car c'est une contrainte du boulot...
Pour le déploiement, j'utilise un fichier build.xml et je l'ex écute
avec
ANT.

Je regarde tout cela demain au boulot et je te tiens au courant.

merci,

matt...

Et puis un autre conseil, pour les appels database, ne fais pas de
l'accès unitaire JDBC, si ton application a de nombreux utilisa teurs,
utilise plutôt une datasource/Pool JDBC fournie par le containe r
Servlet/JSP. Par exemple pour Tomcat prend la datasource du pool JDB C
=> DBCP. Le container va résoudre l'accès à la data base par un look-up
JNDI ( mais tu n'as pas à t'en soucier, c'est le container qui fait
cela, à paramétrer cependant dans web.xml, context.xml).
Tout est expliqué là =>
http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JD BC_Data_Sources

Je ne sais pas si cela est important mais les requêtes sur ma ba se pour
mon application ne sont que des "select".
Les "insert" étant fait pas une autre application. Par contre, i l y a
pas mal de client qui requêtent (une centaine environ).

merci,

matt...

Peu importe le type de requête.
Ce qui es pénalisant pour une database c'est aussi la phase
connexion/deconnexion. L'utilisation d'une datasource et son pool de
connexions associé permet de limiter ces connexions/deconnexions. Il
faut pour cela définir dans ton pool JDBC une taille minimale et une
taille maximale de ton pool, en fonction respectivement du nombre
d'utilisateurs connectés en moyenne à la base ( pool mini) e t du nombre
d'utilisateurs connectés au maximum ( pool maxi). Dans ton cas po ol maxi
=100, et tu peux commencer avec un pool mini=25 par exemple.
En deux mots le principe est le suivant :
- Un appel de de-connexion dans le code ( ds.disconnect()), ne
déconnecte pas obligatoirement la connexion à la base, il re nd d'abord
la connexion au pool. et si le nombre de connexion mini est dépas sé,
alors le pool déconnecte physiquement la connexion à la base .
- Une demande de connexion à la base va générer un appe l de connexion
non occupée parmi les connexions établies du pool, il n'y a pas de
connexion physique puisqu'elle existe déjà( Bien sur si tout es les
connexions du pool sont occupées, on ouvre physiquement une autre
connexion).
Pour MysSQL, la requête showsql permet de suivre ( parmi les nomb reux
paramètres renvoyés) le nombre de threads actifs ( cad les connexions à
la base). Voir avec ton DBA, il te donnera d'autres tips.
J'espère n'avoir pas été trop brouillon dans mes explic ations.

Effectivement, le pool a l'air d'être intéressant car les clie nts ne font
que se connecter et se déconnecter.
Par contre, simultanément, il n'y a jamais 100 clients de connectà © sauf
pas le plus grand des hasards...
Tu n'as pas été trop brouillon car j'ai bien compris (il me se mble) le
principe du pool...

merci,

matt...


--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/

Regardes cette page

http://java.developpez.com/faq/jdbc/?pageÚtaSources

pour la config du datasource...
--
Philippe