Re: [OSM-talk-fr] josm en ligne de commande
Il m'arrive d'effectivement vouloir une seconde instance et mon RC est toujours activé. La solution de Pieren me paraît suffisant pour resoudre le problème de Pierre-Yves. Jo 2014-10-31 1:22 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: Si le RemoteControl a été activé dans les préférences de JOSM, le lancement de la seconde instance de JOSM ne pourra pas activer son propre RemoteControl sqns produire une erreur car le port TCP découte est déjà occupé par la première instance. De fait, JOSM devrait être capabme dans son module d'initialisation de tester si le port d'écoute RemoteControl est déjà occupé en tentant de l'allouer; s'il est déjà occupé il devrait alors essayer de s'y connecter pour lui envoyer une ligne de commande de chargement de données et sortir alors immédiatement en cas d'acceptation. La première instance prendra alors la ligne de commande pour créer un nouveau calque et charger les données demandées; ou simplement s'activer. En aucun cas on ne devrait avoir une seconde instance dès que RemoteControl est activé dans les préférences. Cependnat dans certains cas, le port d'écoute est occupé mais ne répond pas à la requête. Il arrive parfois que c'est une première instance qui est resté dans les choux ou ne s'est pas encore terminée (j'ai déjà vu ça quand on change les préférences et qu'on les valide, pour que JOSM se relance (au redémarrage, le port n'est pas encore complètement libéré et l'initialisation de la nouvelle instance au redémarrage échoue justement à iniitialiser son port d'écoute pour RemoteControl; et on voit l(erreur dans la fenêtre de log). Cela semble ariver du fait que RemoteControl fait tourner son port d'écoute sur un thread séparé du thread principal: bien que la première instance soit théoriquement sortie, en fait seul son thread principal est terminé et se relance (c'est toujours la même insance de la machine virtuelle Java), mais le thread de Remote Control est resté encore actif sans encore sortir quand le nouveau thread principal s'initialiser pour relancer un thread pour RemoteControl... Quand on quitte JOSM; il semble d'ailleurs qu'il faille plusieurs secondes encore pour quele thread d'écoute de RemoteControl se termine (le temps que le GarbageCollector fasse son travail de nettoyage des threads en cours). Il peut arriver parfois que le délai avant que ce port d'écoute soit libéré prenne plus d'une minute car l'exécution de la commande Quitter dans JOSM semble oublier d'envoyer au Thread ReoteControl une commnde lui indiquant de se terminer proprement. D'ailleurs ce thread RemoteControl est particulièrement lent à répondre aux requêtes même dans une utilisation normale à distance depuis un navigateur. Presque à chaque fois le navigateur dignale une erreur de preise en charge de la requete, alors que la requête a bien été acceptée et prise en compte par RemoteControl. Le 30 octobre 2014 18:34, Pieren pier...@gmail.com a écrit : 2014-10-30 18:19 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: java -jar D:\JOSM\josm-tested.jar [--download=] P1070311.JPG P1070312.JPG Mon problème est que si JOSM est déjà ouvert, une autre instance de l'éditeur est créée. Quelqu'un connaîtrait-il les options à ajouter pour empêcher ce comportement ? Cette question serait plus pour la liste @dev-fr . Mais bon, sinon, c'est normal que ta commande crée une nouvelle instance de josm. Si tu veux controller une instance existante, il faudrait passer par le remote control: http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl Je pense que tu peux balancer les commandes depuis ton shell avec un outil genre curl Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] josm en ligne de commande
Bonjour, J'essaie d'ouvrir des fichiers dans JOSM à l'aide de la ligne de commande suivante : *java -jar D:\JOSM\josm-tested.jar [--download=] P1070311.JPG P1070312.JPG* Mon problème est que si JOSM est déjà ouvert, une autre instance de l'éditeur est créée. Quelqu'un connaîtrait-il les options à ajouter pour empêcher ce comportement ? PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] josm en ligne de commande
2014-10-30 18:19 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: java -jar D:\JOSM\josm-tested.jar [--download=] P1070311.JPG P1070312.JPG Mon problème est que si JOSM est déjà ouvert, une autre instance de l'éditeur est créée. Quelqu'un connaîtrait-il les options à ajouter pour empêcher ce comportement ? Cette question serait plus pour la liste @dev-fr . Mais bon, sinon, c'est normal que ta commande crée une nouvelle instance de josm. Si tu veux controller une instance existante, il faudrait passer par le remote control: http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl Je pense que tu peux balancer les commandes depuis ton shell avec un outil genre curl Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] josm en ligne de commande
Merci pour ta réponse. Je vais regarder les outils genre curl. Le 30 octobre 2014 18:34, Pieren pier...@gmail.com a écrit : 2014-10-30 18:19 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: java -jar D:\JOSM\josm-tested.jar [--download=] P1070311.JPG P1070312.JPG Mon problème est que si JOSM est déjà ouvert, une autre instance de l'éditeur est créée. Quelqu'un connaîtrait-il les options à ajouter pour empêcher ce comportement ? Cette question serait plus pour la liste @dev-fr . Mais bon, sinon, c'est normal que ta commande crée une nouvelle instance de josm. Si tu veux controller une instance existante, il faudrait passer par le remote control: http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl Je pense que tu peux balancer les commandes depuis ton shell avec un outil genre curl Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] josm en ligne de commande
Si le RemoteControl a été activé dans les préférences de JOSM, le lancement de la seconde instance de JOSM ne pourra pas activer son propre RemoteControl sqns produire une erreur car le port TCP découte est déjà occupé par la première instance. De fait, JOSM devrait être capabme dans son module d'initialisation de tester si le port d'écoute RemoteControl est déjà occupé en tentant de l'allouer; s'il est déjà occupé il devrait alors essayer de s'y connecter pour lui envoyer une ligne de commande de chargement de données et sortir alors immédiatement en cas d'acceptation. La première instance prendra alors la ligne de commande pour créer un nouveau calque et charger les données demandées; ou simplement s'activer. En aucun cas on ne devrait avoir une seconde instance dès que RemoteControl est activé dans les préférences. Cependnat dans certains cas, le port d'écoute est occupé mais ne répond pas à la requête. Il arrive parfois que c'est une première instance qui est resté dans les choux ou ne s'est pas encore terminée (j'ai déjà vu ça quand on change les préférences et qu'on les valide, pour que JOSM se relance (au redémarrage, le port n'est pas encore complètement libéré et l'initialisation de la nouvelle instance au redémarrage échoue justement à iniitialiser son port d'écoute pour RemoteControl; et on voit l(erreur dans la fenêtre de log). Cela semble ariver du fait que RemoteControl fait tourner son port d'écoute sur un thread séparé du thread principal: bien que la première instance soit théoriquement sortie, en fait seul son thread principal est terminé et se relance (c'est toujours la même insance de la machine virtuelle Java), mais le thread de Remote Control est resté encore actif sans encore sortir quand le nouveau thread principal s'initialiser pour relancer un thread pour RemoteControl... Quand on quitte JOSM; il semble d'ailleurs qu'il faille plusieurs secondes encore pour quele thread d'écoute de RemoteControl se termine (le temps que le GarbageCollector fasse son travail de nettoyage des threads en cours). Il peut arriver parfois que le délai avant que ce port d'écoute soit libéré prenne plus d'une minute car l'exécution de la commande Quitter dans JOSM semble oublier d'envoyer au Thread ReoteControl une commnde lui indiquant de se terminer proprement. D'ailleurs ce thread RemoteControl est particulièrement lent à répondre aux requêtes même dans une utilisation normale à distance depuis un navigateur. Presque à chaque fois le navigateur dignale une erreur de preise en charge de la requete, alors que la requête a bien été acceptée et prise en compte par RemoteControl. Le 30 octobre 2014 18:34, Pieren pier...@gmail.com a écrit : 2014-10-30 18:19 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com: java -jar D:\JOSM\josm-tested.jar [--download=] P1070311.JPG P1070312.JPG Mon problème est que si JOSM est déjà ouvert, une autre instance de l'éditeur est créée. Quelqu'un connaîtrait-il les options à ajouter pour empêcher ce comportement ? Cette question serait plus pour la liste @dev-fr . Mais bon, sinon, c'est normal que ta commande crée une nouvelle instance de josm. Si tu veux controller une instance existante, il faudrait passer par le remote control: http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl Je pense que tu peux balancer les commandes depuis ton shell avec un outil genre curl Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
