Pb Java Tomcat Postgresql

tss, tss, tes problèmes ne sont pas liés à Apple.

La notion de variable d'environnement, c'est pas trop Java ça.
Ensuite, ceux sont tes drivers qui sont spécifiques à un OS.
Le fait est que JDBC est une norme et non pas une implémentation.

Tu as ici le cas précis d'un driver dont les 2 implémentations respectent bien la norme JDBC mais ont des comportements différents ! C'est la base même du polymorphisme et de l'intérêt de passer par JDBC.

Allez courage, Java rules :up:
 
OK c'est vraiment l'échec..

En effet... d'un autre coté, tu ne veux toujours pas faire un simple main avec ton Class.forName et un requête afin de cerner un peu plus près la cause du souci :sleep:.

En fait je dois reprendre tout le code SQL, car ce qui marche sur lynux ne fonctionne pas sur mac (car oui l'application telle qu'elle marche très bien sur lynux).

Comme le dit OlivierL précédemment, il n'y a absolument aucune raison à cela.....

J'ai pour ma part un assez gros projet (300tables) qui tourne en Java, sous serveur d'appli, avec de l'hibernate (et du jdbc) sur du oracle, db2, mssql et postgresql... on est une trentaine de dev, tous OS confondus....


Je vais donc abandonner pour l'instant, puisque le but premier du projet n'est pas de faire fonctionner cette appli sur mac (pas dans le cahier des charges) mais d'améliorer cette application en général.

Ca sera considérablement amélioré si ça tournait nativement sans modif sur les 3 plateformes ! C'est qu'il y a un souci dans le design de l'appli en général si cela ne fonctionne pas.


Je reste quand même profondément frustré de ne trouver aucune explication sur les différences qu'il peut exister entre les 2 systemes d'exploitation au niveau du jdbc, car encore une fois tout cela marche très bien sur lynux, sans changer une ligne de code.
J'ai du chercher dans tous les sens pendant près de 2 mois pour en arriver à cette sombre conclusion : apple déteste les développeurs, pour preuve la complexité de changer les variables d'environnement, info que j'ai mis plus d'une semaine à trouver ici : http://developer.apple.com/qa/qa2001/qa1067.html/QUOTE]

Une preuve de plus qu'il y a qq chose qui cloche... Je ne vois pas pour quelle raison tu aurais besoin d'avoir des variables d'environnement !!!
 
Ok j'ai bien compris pour le message d'OliverL, c'est vrai que mes problèmes de driver mettent bien en relief l'intérêt de passer par le JDBC, je pense que je rajouterais ça dans mon dossier!! merci
C'est vrai que je m'exite un peu sur Apple qui n'y est surement pour rien, le vrai pb vient de ma lassitude, mais qu'est-ce qui pouvait me faire croire que ce serait facile?

Pour GrandGibus, j'essaye de faire ce main, mais pour montrer toute la procédure j'ai besoin de bien comprendre chaque méthode de chaque classe, car le code est incroyablement touffu et complexe, et l'architecture.. ben y'en a pas! C'est une appli développer dans les années 90, plusieurs fois reprises, et très mal pensée à la base. C'est pourquoi faire un main s'avère bien compliqué, dès que c'est près je l'envois. Je pensais que le problème venait du code, mais tu sembles dire que c'est impossible.. Franchement j'en serais ravi..

Le mieux serait de reprendre l'appli à la base et de tout refaire, mais hélas je n'ai que 2 mois impartis à ce projet, donc pour l'instant je résoud les bugs du cahier des charges, je fais les ajouts demandés, mais si j'ai fini en avance, ce qui sera surement le cas, j'aimerais faire quelques changements d'archi un peu plus important, et notamment réussir à faire tourner ça sur mac.

Bref il faut que je me remotive vite, et grâce a vous c'est plus facile. merci bien, je suis vraiment content d'avoir découvert ce forum :up:, a bientot

PS : la variable d'env c'est pour éviter d'utiliser l'un des moultes chemins en dur qui trainent au long de l'appli, bien que cette solution ne soit finalement guère efficace, puisque l'utilisateur doit alors être capable d'ajouter une de ces variables manuellement ( Je pensais naïvement au début que lors de l'installation de tomcat par exemple, un script magique aller ajouter la variable d'env TOMCAT_HOME - maintenant CATALINA_HOME - dans les variables d'env.. C'est juste une illusion, a peine une sensa..:siffle: enfin vous connaissez la suite )
 
Pour GrandGibus, j'essaye de faire ce main, mais pour montrer toute la procédure j'ai besoin de bien comprendre chaque méthode de chaque classe, car le code est incroyablement touffu et complexe, et l'architecture.. ben y'en a pas! C'est une appli développer dans les années 90, plusieurs fois reprises, et très mal pensée à la base. C'est pourquoi faire un main s'avère bien compliqué, dès que c'est près je l'envois. Je pensais que le problème venait du code, mais tu sembles dire que c'est impossible.. Franchement j'en serais ravi..

Le but n'est pas de mettre toute ton appli dans un main, mais juste deux/trois instructions avec:
  • l'instanciation du driver JDBC
  • l'exécution d'une requête type
  • l'affichage des résultats (System.out.println...)
Ca sera ainsi bien plus aisé de faire le diagnostic, tu pourras aussi déboguer facilement...


PS : la variable d'env c'est pour éviter d'utiliser l'un des moultes chemins en dur qui trainent au long de l'appli, bien que cette solution ne soit finalement guère efficace, puisque l'utilisateur doit alors être capable d'ajouter une de ces variables manuellement ( Je pensais naïvement au début que lors de l'installation de tomcat par exemple, un script magique aller ajouter la variable d'env TOMCAT_HOME - maintenant CATALINA_HOME - dans les variables d'env.. C'est juste une illusion, a peine une sensa..:siffle: enfin vous connaissez la suite )
Une manière plus élégante serait de:
  • passer par un fichier .properties (lui-même inclu dans le jar) qui contiendrait les chemins d'accés
  • de passer par des -DmyPath="C:\toto" au lancement de la jvm (et dans le code un System.getProperties(...))
donc, pas de nécessité de passer par des variables d'environnement ;).
 
J'approuve totalement le passage par des paramètres de la JVM proposé par GrandGibus.:up:
Dans Eclipse, Window>Preference>Tomcat>Paramètrages de la JVM.

Par contre, je persiste à dire qu'une batterie de test JUnit, c'est mieux que des simples main().
D'autant plus qu'avec Eclipse, ca se fait tout seul...;)
 
Pour le main, ça ne servirait à rien, car ma connexion marche bien.

Par contre quand je modifie le code :
- en fermant correctement les statements (après la fermeture du resultset)

- en modifiant des classes pour que les resultset, statement et connexion soit dans la meme classe (car actuellement certaines classes appellent des fonctions d'une classe SQL qui récupère la connexion et renvoi un statement créé sur cette connexion)

En corrigeant ça, tout fonctionne, sur mac et linux! mais c'est trop long a faire pour tout le code..


Une manière plus élégante serait de:
  • passer par un fichier .properties (lui-même inclu dans le jar) qui contiendrait les chemins d'accés
=> un fichier .properties est déjà utilisé, mais les variables ne sont pas accessibles depuis une classe java.. (sauf en lisant le fichier mais c'est pas génial)

  • de passer par des -DmyPath="C:\toto" au lancement de la jvm (et dans le code un System.getProperties(...))
=> je vais essayer ça merci, meme si ma solution à été validée par mon maitre de stage.;-)

En tout cas merci bcp :zen: ces forums sont fantastiques! très longue vie, vous aurez vite de mes nouvelles