Ubuntu-fr

Stef38

Problème accés lors du déploiment d'un JDBC driver derbyclient

Bonjour à tous,

Je suis nouveau sur ce forum et dans le monde des servlet, tomcat et netbeans.

Je dois, dans le cadre d'un exercice de cours, faire un accés à une base de données javaDB d'exemple.
Lors de l'execution j'ai ceci :

Checking data source definitions for missing JDBC drivers...
Deploying JDBC driver to /usr/share/tomcat6/lib/derbyclient.jar
WARNING: Cannot deploy the JDBC driver to /usr/share/tomcat6/lib/derbyclient.jar.
Check whether you have write access rights to the /usr/share/tomcat6/lib folder.
Incrementally deploying http://localhost:8080/test
Completed incremental distribution of http://localhost:8080/test

Pour info :
j'utilise Netbeans 6.9.1 lancé de mon utilisateur.
TomCat6
Et je suis sous Ubuntu 10.04.

Qui pourrais m'aider à résoudre mon problème ?

Merci

Stéphane

Dernière modification par Stef38 (Le 05/10/2010, à 09:10)

funkalee

Re : Problème accés lors du déploiment d'un JDBC driver derbyclient

Il faut lancer javadb(derby) pour y accéder, utilise le tomcat de netbeans au moins pour tester que cela marche, après tu pourra déployer sur le celui du système.

Des cours avec jdbc , mon dieu..... heureusement que JPA n'existe pas, l'école a bien 10 ans de retard sur ce qui se passe dans le monde de la réalité

Dernière modification par funkalee (Le 07/10/2010, à 03:20)

ssdg

Re : Problème accés lors du déploiment d'un JDBC driver derbyclient

funkaii> JPA c'est bien, mais c'est du JEE, que faire si tu fais une application Java SE ? (oui, hibernate, je sais)

Et si tu as des requêtes complexes à faire? (tu cherche tous les clients qui ont un compte qui a eu moins de 20% de sa valeur actuelle retirée au cours des 6 derniers mois... ça commence à devenir compliqué pour du hql non? (je suis pas encore très au point, coté hibernate, mais je crois que ça se complique)

Et si tu as une énorme tripotée de résultats qu'il faut juste mettre sous forme de tableau, une telle machine de guerre vaut elle le coup? (même coté perfs, c'est pas génial)

M'enfin bon, tout ça pour dire qu'hibernate est très utile, mais JDBC a encore son utilité.

---

s'il n'y a pas de solution, c'est qu'il n'y a pas de problème... ou pas.

funkalee

Re : Problème accés lors du déploiment d'un JDBC driver derbyclient

JPA est dans la categorie JEE, mais JDBC aussi
hql n'est pas du JEE, c'est du hibernate pur qui n'est pas un standard, dans jpa il existe la possibilité de faire des requêtes natives
ex :

import javax.persistence.EntityManager;

EntityManager em;

  public User findUserByLogin(String login) {
    Query query = em.createNativeQuery("SELECT u FROM User u WHERE u.login = :login").setParameter("login", login);
    return (User) query.getSingleResult();
  }

Donc c'est possible à condition de chercher un minimum
quand tu as beaucoup de résultats tu utilises les fonctions setMaxResults(), setFirstResult(), jdbc je veux bien mais avec spring, en revanche faut arrêter d'enseigner le java d'il y a 10 ans.

Dernière modification par funkalee (Le 08/10/2010, à 11:26)

ssdg

Re : Problème accés lors du déploiment d'un JDBC driver derbyclient

Si on se base là dessus: http://download.oracle.com/javase/1.4.2/docs/api/java/sql/package-summary.html (et sur le fait que je n'ai pas eu à installer un serveur d'appli pour en faire en fac), JDBC c'est du Java "core". Une bonne partie des classes de la norme est même dans "java.sql.*".

Ajoutons que tu n'a pas forcément envie de définir un mapping objet quand tu t'intéresse juste au petit affichage d'une table.

Je ne dit pas que:
1) ce n'est pas pratique d'avoir un ORM. loin de là, je suis même en faveur de l'usage de ces choses quand c'est un gain de temps (à vue de nez, 90% du temps)
2) JDBC permet de faire les choses vite et bien. (là encore, récupérer des données dans un format non objet est en contradiction avec l'esprit du langage)
3) hibernate est un standard, mais je reconnait que ma formulation laissait un doute.

Donc,  oui, je JPA (et les ORM en général) est une tuerie (dans le sens que ça roxx du castor poudré dans un sous marin suisse) mais il ne faut pas oublier qu'il existe encore des applications "poste" qui se servent de ce genre de technos, qu'un jour ou l'autre on a tous un petit test jUnit ou une interface quick&Dirty a faire et où un ORM serait superflu et que sous les ORM, je ne serait pas surpris de trouver du JDBC. (bien caché, mais ce serait comme dire que dans les avions le concept de roue est devenu inutile)

Sinon, Stef38: alors, ça marche?

---

s'il n'y a pas de solution, c'est qu'il n'y a pas de problème... ou pas.