Reprise du message précédent :

sureprenant d'avoir des méthodes statiques sur une classe récupérée via le design pattern singleton ...
 

ca veut dire que tu les réinitialises à chaque requête ... c'est pas ce qu'il y a de plus optimal

bah j'ai besoin de méthodes statiques pour mes getInstance et getAllInstances.
Le premier me permet de récupérer une instance de la classe en ne lui passant que le numéro de l'objet. Il va rechercher dans la bdd les infos de cet objet grace à ce numéro/id.
le deuxième me permet de récupérer toutes les instances d'un objet et je ne peux clairement pas le faire sans méthode statique.
 

bah en fait je ne vois pas comment faire autrement. J'ai pas mal de classes métiers et je n'ai pas toujours besoin de toutes. selon l'url passé et les arguments, je vais ensuite construire mes objets.
mais a vrai dire je ne connais pas bien la méthode init et comment on peut l'utiliser. peux tu m'éclairer sur ce point ?

je vois vraiment aucune raison qui pourrait t'empecher de passer par des méthodes non-static ...
 
C'est qui qui t'y obliges d'après toi ?
 

la méthode init est là pour te permettre d'initialiser ou de récupérer des objets dont tu auras besoin par la suite. Ca te permet de le faire une fois pour toute plutot que de faire la même opération systématiquement. Par exemple, récupérer ton DataSource. A quoi ca te sert d'aller le chercher à chaque requête ?? Tu récupères toujours le même ...
 
bien sûr, pour tout ce qui dépend de paramètres passés dans la requête, tu ne peux pas le faire dans la méthod init() ...

+1, et commencer à tout passer en static parce que ça coince ailleurs, ça sent le ranse.
 

+2    

mais pour mon getAllInstances. je vais tout de même pas récupérer toutes les instances d'une classe à partir d'une instance particulière ? ça me semble pas logique là

 
Oops, c'est moi ça Et le passage de private à public aussi, ca simplifie les choses parfois

moi j'ai des méthodes statiques que je peux enlever chui d'accord mais pas pour les 2 méthodes dont j'ai parlé ca me semble pas logique.
sauf peut être mon getInstance, il suffirait que je rende le constructeur public.

 
si ton getInstance() c'est juste pour le design pattern singleton, c'est normal qu'il soit static.
Par contre si il fait des requêtes en base ou se genre de chose, là c'est plus normal ...
 
 
et d'après le code que tu as donné, c'est ce que fait ton getAllInstances() n'a pas à être fait dans une méthode static (d'ailleur dans le code que tu as filé, elle n'est pas static)

qu'est ce que tu appelles instance ? instance de quoi ?
 
Tu pourrait préciser quels sont les différents objets dont on parle et quels sont leur fonction ?
parce que ca commence à s'embrouiller un  peu là

Ok alors par exmple pour ma classe métier Company. Elle permet de créer une entreprise et récupère pour cela les information de la bdd qui référencent les entreprises.
 
voici mes méthodes getInstances et getAllInstances :
 

 
est ce que c'est plus clair ?

bon j'ai clairement un problème avec mes conneries de static pas static
 
de ce fait j'arrive pas à utiliser correctement la variable de classe QueryBroker
 
est-ce que mes méthodes getInstance et getAllInstances ne doivent vraiment pas être statiques ? ou alors si elles doivent l'être mais qu'elles ne doivent pas faire de requêtes je fais comment ?

disons que là c'est de la programmation procédurale que tu fais, pas de la programmation objet ...
 
Rien de très gênant en soit, si ce n'est que c'est pas très beau et que tu perds en évolutivité ...  
 
Ca risque de te prendre pas mal de temps et d'effort si tu veux tout refaire en object.
 
 
En gros, à la place d'avoir des méthodes static, tu devrais avoir un autre objet qui te permet de récupérer les instances d'objets Company. Cet objet devrait posséder une instance de QueryBroker pour pouvoir accéder à la base de données. Et QuerryBroker devra posséder un DataSource qu'il récupère dans le Context.
 
par cette méthode, tu évites d'avoir à mettre des static partout.

ouais ça va me demander beaucoup de boulot là
et puis c'est toute ma logique de conception qui en prend un coup.
 
m'enfin le pire c'est que c'est ce que j'ai appris en cours et  j'avais un bon prof... je lui demanderai son avis si ça se trouve lui aussi il va s'arracher les cheveux
 
edit : alors du coup je fais comment avec ma variable QueryBroker qui me zut grave ?

en même temps, c'est un peu extremiste de vouloir virer tous les static ... ca peut très bien marcher avec, mais sur la longueur tu t'aperçois que c'est plus gênant qu'autre chose, sauf pour quelques méthodes utilitaires qui ne nécessite pas de contexte d'execution.
 
Mais là, toi dans ton cas tu fais des accès à des base de données et tout ... du coup, tu es obligé de construire l'instance qui te permet d'accéder à la base de donnée à chaque fois, ou bien de la déclarer static elle aussi, ce qui est assez crade ...

mais comment je devrais faire simplement alors ?

QueryBrocker
 -> constructeur : va chercher le DataSource et le stocke en variable de classe
 -> executeQuery(query) : execute la requête et retourne un resultset
 
 
CompanyManager
 -> constructeur(QueryBrocker) : stocke le QueryBrocker en variable de classe
 ->getInstance(companyNum) : utilise le QueryBrocker pour retrouver la compagnie en base
 ->getAllInstances() : utilise le QueryBrocker pour retrouver toutes les compagnies en base
 
etc.
 
remarque : si les objet Compagnie peuvent se mettre à jour tout seul, il faut que tu leur passes l'objet QueryBrocker à la construction
 
 
avec une architecture de ce style, tu n'as plus de méthode static ...

je vais voir pour faire ça
 
sinon a priori je gère mieux mes exceptions puisque j'ai une SQLException qui a été catché par une servlet. le problème c'est que je me tape une java.lang.IllegalStateException sur cette ligne : "response.sendError(500, "BDD error during add options of a CustomerProduct" );" (ligne qui est dans un catch de mon doPost).
 
c'est normal ça ? parce que c'est une ligne que m'a donné quelqu'un ici

ouais c'est moi.
 
le response.sendError() ne peut être utilisé que si tu n'as pas encore commencé à érire. Et après que tu ais fait le sendError, tu n'as plus le droit d'écrire non plus.
 
Tu aurais pas oublié le "return;" juste après le sendError() ? (erreur classique)

ah ya un return après le sendError ?  
 
j'avais fait comme ça :

le "return;" c'est une façon simple pour arrêter le traitement à ce moment là.
 
Là j'imagine que à la suite de ton catch tu fais le traitement "normal" => tu écris quelque chose ou tu fais dispatch vers une jsp ...

dans ce cas je dispatch vers une jsp, mais des fois j'ai aussi mis le dispatch dans le try.

t'as deux solutions : soit tu mets un return, soit tu t'assures de pas faire de dispatch après le sendError.
 
Mais peut être que ce que tu préferais faire c'est un dispatch vers une page d'erreur plutot qu'un sendError() ... enfin à toi de voir ...

je ferai une page d'erreur je pense, mais pas tout de suite, c'est pas ma priorité
 
  bon sinon j'ai trouvé la source de mon NullPointerException qui pétait de temps en temps !
Alors voilà ce que j'ai d'affiché :

Ok alors maintenant je vais devoir trouver pourquoi j'ai cette erreur qui pète... peut être un problème de paramétrage...
 
en tout cas chui contente d'avoir mon explication moua

c'est pas plutot du au fait que tu ne fermes pas toujours tes connections ? genre apres une exception, le close passe a la trappe ? => voir la clause finally apres un try catch pour liberer une connection
 
edit: par la j'insinue pas que tu ne le fais pas je suggere juste une cause possible

hier j'avais regardé par là. j'avais bien toujours une clause finally pour fermer mon resultset mais... je l'avais pas fait pour closer mes preparedStatement.
Une fois l'oubli corrigé j'ai retesté mais j'avais tjs le même problème
 
bon je regarderai tout à l'heure les différentes causes possibles et tout et tout.

pour fermer le resultset, mais l'objet QueryBroker ferme t'il les connections ?

justement chui en train de regarder ça, à mon avis ça vient de là c'est clair !

bon j'ai toujours mon problème. je sais que ça vient du QueryBroker alors je l'ai un peu modifié ainsi que mes classes et servlet. J'aimerai avoir votre avis.
 

Alors je sais mon constructeur à un catch qu'il ne devrai pas, mais je pense régler ça après que mon truc marche
j'ai fait une nouvelle méthode close() pour fermer ma connection, mon statement et mon resultset.
 
ex pour ma servlet HomeController

Ici vous pouvez voir que j'ai mon queryBroker en variable privée. Je passe ensuite cette variable à mes méthodes des différentes classes métiers.
Je pensais que ce serait bon en initialisant mon broker au moment du init et en le closant au moment du destroy. Apparemment c pas ça

Remarque un peu hors sujet mais interessante quand meme : Ca serait bien de logger avec log4j ou consort : après tu as une meilleure vision de ce qui se passe...
 
Que tu fasses de l'objet, du SQL, du script shell, il faut logger proprement avec des niveaux de logs (INFO, WARN, DEBUG). Si tu avais tout bien loggué toutes les exceptions, tu aurais peut etre vu le probleme de pool de connexion depuis belle lurette....

bah chui pas trop au fait de ces choses alors je faisais au pifomètre

j'implore un gros OSKOOOOOOOOOOR
 
       
 
je ferme bien mes connexions non ? pourquoi alors j'ai cette satanée erreur ? Moi qui pensais que j'allais résoudre ça facilement chui larguée

 
 
dsl je dois etre fatigué mais ou est ce que tu appelles la méthode close de ton QueryBroker hormis dans le destroy de ta servlet ?

alors je l'appelait que dans le destroy. je m'étais dit que ct suffisant.
depuis j'ai viré l'init et le destroy et bloc try catch existant, j'initialise en premier le broker et j'ai fait un finally où j'appele le close.
 
ex :

 
 
J'ai peut etre une question à l'ouest, mais es tu sur que le close sur le _queryBroker libère bien ta connection ?

j'ai mis plus haut le contenu de mon close()
 
sinon j'veux bien savoir comment on libère cette *#$µ&!#*$ de connexion !

 
Qd tu fais un forward, le destroy de la servlet se fait a tous les coups ? (manque de culture inside)
J'ai mis en place des Datasources comme toi, et je n'ai jms rencontré ce genre d'erreur...
 
La différence est que j'ai mon singleton qui contient une datasource, et j'ai une méthode getConnection (qui fait le getConnection sur la datasource), et un freeConnection(laconnection)
 
Donc ds mes objets, je créé les objets resultset et prepareStatment, et les closes ds des finally (avec la methode de liberation de la connection)
 
ps: Par contre, je me suis rendu compte que j'ai mis mon objet Connection en statique, pas bien.

donc en gros tu vois pas où j'ai boulaytisé ?

mets un system.err... avt et apres ton _queryBroker.close pour etre sur que tu y passes bien ?

Bah oué il y passe bien
 
bon est-ce que ça pourrait venir du paramétrage de ma base ?

ou du paramètrage de la datasource....

question conne hein, mais ton query broker c'est un singleton qui utilise une connection donnée, deux clients attaquent ton site web, les deux threads utilisent ton query broker, le premier close ta connection, qu'arrive t'il au second ?
 
c'est moi qui a mal suivi ou y a une grosse coucouille là ? ce serait mieux si c'était pas un singleton et que tu avais bien une connection par thread nan ? paske la bon...ton pool de connection il a la vie un peu tranquile j'ai l'impression
 
(quelque chose me dit que je viens de dire une connerie et que plusieurs post m'ont échappé nan ? )