Newsgroup: it.comp.java
Titolo: Lanciare una sola volta l'applicazione

Salve a tutti.
Ho la necessità di dover  bloccare (in ambiente unix e quindi multiutente)
il lancio di una applicazione java se questa è già in esecuzione sulla
macchina.
Come posso effettuare un controllo in tal senso?
Devo farlo da sistema tramite shell o posso farlo da codice java
direttamente?
Lavoro in AIX.
    danilo

 ha scritto nel messaggio
news:2kvonqF...@uni-berlin.de...

A me hanno sempre suggerito un trick interessante ma non so se sicuro...
Crei un server socket su una determinata porta... se c'è una porta gia
occupata da un altro socket, viene lanciata un'eccezione e la gestisci come
meglio credi.


Interessante anche se ho già risolto da shell, però non male
l'idea (se non si ha possibilità di farlo da shell)
    danilo

Perchè non aprire un apposito file in scrittura? 

 Perchè non aprire un apposito file in scrittura?
Si ma dove andrebbe scritto il file?
E con i permessi come la mettiamo?
    danilo

danilo_NO wrote:

Non ho capito il problema. Comunque ad esempio in /var/lock/lock_tua_app
oppure un file temporaneo in /tmp. Per quanto riguarda i permessi mi
spiegeresti meglio, per favore, qual è il problema?
Nel caso dei socket è necessario legarsi a una porta "specifica" (oltre la
1024 per non avere problemi di permessi). Ma se viene occupata da un'altra
applicazione come lo capisci? 

 applicazione come lo capisci?
Magari le due istanze del programma possono comunicare per capire se sono
loro.
Il primo che apre il socket se lo trova occupato ci si connette e manda una
stringa. Se la risposta è buona ok, altrimenti la porta era occupata da
un'altra applicazione e prova con quella dopo.
Certo si manda immondizia agli altri programmi, ma chi li ha fatti dovrebbe
aspettarsi anche questo :)
Ciao
Matteo
-- 
chi sono e soprattutto chi non sono:
http://www.ilnomedeldominio.it
un piccolo programma per studenti universitari:
http://inutility.ilnomedeldominio.it/imsv/

 spiegeresti meglio, per favore, qual è il problema?
Il problema e' che se vuoi scrivere un'applicazione che sia
indipendente dal sistema operativo non hai la minima idea della
struttura del filesystem che hai sotto.
Ad esempio /var/lock/ e' una directory che esiste in un ambiente
Unix-like (come linux) ma non in un ambiente windows.
Inoltre anche sapendo qual'e' l'ambiente target l'utente che esegue
l'applicazione potrebbe non avere di permessi di scrittura sulla
cartella scelta e il risultato sarebbe che non e' possibile creare
il file (e magari neanche verificare se e' stato creato se mancano
anche i permessi di lettura).
Andrea
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Matteo
Non capisco il tono sarcastico. So benissimo che possono comunicare.
So benissimo che per andare da Bari a Foggia si puņ passare per Milano.
La mia "proposta" era di utilizzare un file come tra l'altro fanno tutti i
programmi unix che hanno il requisito richiesto.
Vorrei che il tono si riabbassasse.

 programmi unix che hanno il requisito richiesto.
E io non ho detto che fa schifo, ho solo risposto ad una domanda :)


Andrea Polci wrote:

Java invece è indipendente. 
Il metodo "File.createTempFile();" crea un file nella directory temporanea
di default del sistema. 
In ogni caso l'applicazione potrà ben scrivere da qualche parte (nota a
priori) sul filesystem. Di solito è possibile leggere e scrivere dei file
di configurazione, serializzare oggetti...
Se mettiamo tra i requisiti quello di non scrivere sul filesystem vada per i
socket. 
Per quanto riguarda i permessi è ovvio che chi deve usare l'applicazione
deve avere permessi adeguati.

Ciao, Andrea!
Il giorno 07/07/2004 alle ore 12:37 hai scritto:
 AP> Ad esempio /var/lock/ e' una directory che esiste in un ambiente
 AP> Unix-like (come linux) ma non in un ambiente windows.
 AP> Inoltre anche sapendo qual'e' l'ambiente target l'utente che esegue
 AP> l'applicazione potrebbe non avere di permessi di scrittura sulla
 AP> cartella scelta e il risultato sarebbe che non e' possibile creare
 AP> il file (e magari neanche verificare se e' stato creato se mancano
 AP> anche i permessi di lettura).
C'e' qualche alternativa, come per esempio utilizzare le proprieta' di
sistema (java.home per esempio) oppure leggere le variabili di ambiente (di
solito una variabile TEMP esiste sempre). Si puo' anche andare per tentativi
leggendo il tipo di sistema operativo (
os.name
) e testando la presenza di
directory comuni (/tmp in Linux, /WINDOWS/TEMP in Windows, ecc.), non
garantisce risultati ma ci si avvicina.
Piuttosto il problema principale nell'usare un file come flag e' quello che
il file rimane se non viene esplicitamente cancellato. Nel caso in cui il
programma vada in crash o comunque non termini nel modo giusto si ottiene un
risultato fallato.
Molto meglio utilizzare un sistema che "auto cancelli" i flag quando il
programma termina. Il socket da questo punto di vista e' piuttosto preciso e
portabile (localhost esiste sempre in genere). Il controllo dei processi
attivi sarebbe ancora meglio, purtroppo e' facilmente implementabile solo su
*nix, in ambiente Windows occorre fornire un programmino apposta per
elencare i processi attivi.
Certo sarebbe l'ideale fare programmi che non risentano eccessivamente del
fatto che vengono lanciati due volte, ma non si puo' avere tutto.
Bye
-- 
There is no death; There is the Force.
http://www.maccasoft.com


Se sulla rete hanno lockato tutte le porte ( frequente)
potresti avere problemi anche usando 127
Il file invece e' inusabile perche' e' improbabile che hai i grants
P.S. per curiosita' , ci diresti come hai fatto con la shell ?
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/