Bonjour Guihlem
J'ai regardé plus en détails le code pour les MBeans et j'ai fait quelque
nettoyage. Je ne suis par certain de n'avoir rien cassé puisque je ne suis pas
familier des MBeans...
* Il y avait un constructeur qui attendait un WebServiceWorker en argument.
Je comprend que c'était commode pour construire un WebServiceManager et
lui donner immédiatement un premier worker. Mais pour la construction du
manager en tant que tel, le constructeur n'avait absolument pas besoin
d'un worker. Essaie de respecter "une méthode == un job" autant que possible.
J'ai effacé l'argument du constructeur.
* J'ai déplacé "net.seagis.management" dans "net.seagis.coverage.web". Pour
l'instant, il reste encore dédiés aux WebServiceWorker. Ce déménagement
permet de garder des classes "package privated".
* J'ai fusionné WebServiceJMXHandler dans WebServiceManager. Je n'ai pas
vraiment vu de raison pour cette séparation. Ce WebServiceManager me
servira plus tard à contenir d'autres informations à partager entre les
WebServiceWorker.
* Dans WebServiceManager.flush(), en cas d'échec tu logs un message. C'est
bien sauf que le niveau SEVERE est trop élevé - il est généralement réservé
aux échecs qui mettent réellement en danger la stabilité du system. Dans ce
cas si, si on n'a pas réussi à vider la cache, tant pis. Il restera peut-être
des fichiers en trop dans le répertoire temporaire, mais le système ne va pas
s'écrouler. Le niveau WARNING suffit. Même chose en cas d'échec
d'enregistrement du MBeans. Si on échoue, tant pis il n'y aura pas de MBeans.
Mais le reste du système va quand-même fonctionner.
* En cas d'échec d'enregistrement du MBeans, tu fais un "try" suivit de tout
un tas de "catch". Une vérification dans la javadoc permet de vérifier que
toutes ces exceptions héritent de javax.management.JMException. On peut donc
n'attraper que cette dernière - ça évite de répéter la même gestion plein de
fois. Si le seul parent avait été java.lang.Exception, ça n'aurait pas été
acceptable (c'est trop vaste). Mais javax.management.JMException me semble
suffisament précis. C'est comme attraper toutes les java.io.IOException.
* Pas la peine d'attraper NullPointerException. Si cette dernière est lancée,
c'est qu'il y a un bug dans notre code - pas un problème d'enregistrement
indépendant de notre volonté. On veut laisser propager cette exception pour
nous forcer à corriger de tels bugs.
* Avant d'enregistrer le MBeans, tu vérifiais si un autre MBeans n'était pas
déjà enregistré sous ce même nom et le dé-enregistrait si c'était le cas.
J'ai supprimé cette vérification - nous ne savons pas à qui appartenait le
MBeans déjà enregistré (même si on peut présumer que c'est nous, une collision
de nom reste possible). En cas de MBeans pré-existant, on veut être prévenu
sous la forme de InstanceAlreadyExistsException, qui sera loggé dans le bloc
"catch".
* Le nom "WebServiceManager:name=WebServiceManager" est peut-être problématique.
J'ai regardé très vite fait et j'ai l'impression que le Java utilise leur nom
de package "java.lang...". Il faudrait peut-être que "net.seagis" apparaissent
à quelque part justement pour éviter les collision de nom (aucune chance pour
que l'on soit les seuls à appeller une classe "WebServiceManager"). Faudrait
voir quelle est la pratique - il doit y avoir des recommandations dans la
documentation de MBeans.
* J'ai renommé la méthode "undeploy..." en "dispose" et j'appelle "dispose"
sur chaque workers, que je retire ensuite de la liste.
* J'ai vu que WebServiceWorker.dispose() appellait WebServiceManager.dispose()
quand le nombre de worker atteint zero. Ca devrait être dans l'autre sens:
WebServiceManager.dispose() qui appelle WebServiceWorker.dispose() de chaque
worker.
* J'ai supprimé la méthode qui donnait le temps de création de la dernière
image. Son implémentation était problématique car il y avait une seule
variable mesurant le temps dans WebServiceManager alors qu'on s'attend à
avoir plusieurs WebServiceWorker tournant en parallèle. Cette variable
aurait du être dans WebServiceWorker directement, et WebServiceManager
aurait choisit le dernier worker utilisé. J'aurais pu corriger mais vu
que cette information n'était pas crucial et de peu d'intérêt comparativement
au profiler, je l'ai supprimé.
Voilà pour les commentaires. Maintenant quand je lance Maven, j'obtiens:
[INFO] Failed to resolve artifact.
Missing:
----------
1) jersey:jersey:jar:0.5-ea
Path to dependency:
1) net.seagis:web-services:war:1.0-SNAPSHOT
2) jersey:jersey:jar:0.5-ea
Je ne suis donc pas certain de ne pas avoir brisé le web service. Il faudrait
peut-être mettre à jour le pom.xml du module "web-service"?
Bonne journée,
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
