Newsgroup: it.comp.java
Titolo: Sapere se sono in debug

Si può sapere a livello di codice se si è in debug o meno?
Quando sono in debug dovre fare determiate cose, altrimenti
dovrei farne delle altre.
In Visual C++ si poteva.
In Java su Eclipse????
Ciao e grazie.

 ha scritto nel messaggio 
news:fbh64e$mah$1...@carabinieri.cs.interbusiness.it...

posso chiedere che tipo di cose vorresti fare in debug?


Tipo aprire una connessione al DB piuttosto che un'altra.
Solo che non voglio tutte le volte fare delle modifiche al codice.
Vorrei che da programma si potesse capire e decidere se
aprire una o l'altra.
Ciao e grazie.

 ha scritto nel messaggio 
news:fbh6pl$rj2$1...@balena.cs.interbusiness.it...

Solitamente per questo tipo di cose si fanno build separate.
Ad esempio i settaggi delle connessioni sono solitamente esternalizzati in 
un file xml.
Quindi avrai un settings.xml per la build normale, e un settings-test.xml 
per la build di test (o debug).
Devi quindi solamente parametrizzare il processo di build dell'applicazione 
(facile da fare con ant o maven) in modo da utilizzare un file xml oppure 
l'altro.
Stai usando ant per la build dell'applicazione? 

 Stai usando ant per la build dell'applicazione?
No, uso lo standard eclipse.
Ciao e grazie. 

 ha scritto nel messaggio 
news:fbh64e$mah$1...@carabinieri.cs.interbusiness.it...


 Era proprio quello che non volevo fare.
e' proprio quello che faccio io con maven.
Con maven puoi specificare diversi profili / parametri.
Se ho un db per il test o debug creo il war in questo modo:
mvn package -P debug
ad esempio
...niente di piu' comodo
con ant farei una cosa simile:
lascia pure che Eclipse normale faccia il suo solito lavoro di compilazione 
e copia dei file.Poi lanci lo script ant che copia il file xml corretto (o 
il file di properties forse) nel classpath (o dove vuoi).
Eclipse e' altamente integrabile con ant (quasi tutti lo utilizzano cosi'). 

 diverso a seconda se sono in debug o in produzione (e non uso ant)
Setta il parametro in un file di properties che l'applicazione andra' a 
leggere.

Sboffo (03/09/2007 16.40.26):

Secondo me è un errore concettuale il fatto che l'applicazione possa
sapere di essere in fase di debug. Un po' come il principio di
indeterminazione di Heisenberg, la cui conseguenza è che il solo fatto
di osservare un oggetto (una particella subatomica) ne cambia le
proprietà. Niente di più deleterio per la programmazione.
Il codice compilato non deve (non "dovrebbe") cambiare comportamento
intrinseco nel momento in cui sei in debug: significa che stai
osservando un comportamento che in produzione non avverrà mai. Invece,
come dice cicap,  è più accettabile (e preferibile) lanciare lo stesso
programma con due configurazioni diverse: possono effettivamente
riferirsi a due ambienti diversi.
-- 
Scientology: se la conosci la eviti, se la conosci non ti uccide...
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx
 - 
http://www.xenu.net
(per rispondere personalmente leva IlDitoDalCulo)
---> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 <---

 osservando un comportamento che in produzione non avverrà mai.
Quindi secondo te sarebbe meglio riavviare l'intera web application ogni 
volta che mi accorgo che ho scritto "codice clionte" anzichè "codice 
cliente"?
B.

 Ovviamente questo comportamento non deve avvenire in produzione
Secondo me stai facendo una gran confusione fra debug, produzione e
configurazione. Se la tua applicazione prevede un debug modo così
complesso, allora dovrei perdere tempo a debuggare il debug mode....usa un
processo di configurazione che sia sempre quello e cambia le opzioni di
configurazione durante il debug.
Luca


Scusa ma non ho capito a livello pratico cosa dovrei fare.


Anche secondo me stai facendo confusione.
Il debug e' un procedimento eccezionale, che si puo' fare quando hai un bug 
da eliminare.
Ora che senso ha voler cambiare il file di property durante il debug? Hai un 
esempio di questo modo di procedere?
Se vuoi essere sicuro che il tuo codice "funzioni" con vari dati e 
configurazioni, allora dovresti farlo tramite varie tipologie di test 
automatici.
Testare un applicazione non significa farne il debug. 


Forse ho un modo sbagliato di sviluppare. Io faccio di solito cosě:
- Avvio Eclipse e apro il progetto.
- Faccio le modifiche del caso.
- Lancio Tomcat in debug mode (da dentro Eclipse)
- Metto eventualmente dei breakpoints
- Se mi accorgo che c'č un errore in qualche classe lo modifico e lo ritesto 
fino a quando non funziona. In genere le modifiche le faccio senza riavviare 
Tomcat, a meno che non modifico qualche interfaccia pubblica della classe 
(in questo caso Eclipse mi costringe a riavviare Tomcat)
Dove sbaglio?
B.

Ho risolto cosě.
Imposto una variabile a livello di virtual machine (col parametro -D)
e poi la leggo dentro il codice.
Ciao e grazie.
Sboffo. 

è totalmente sbagliato quello che vuoi fare.
essere in debug è BEN DIVERSO dal far girare l'applicazione configurata per 
l'ambiente di test/sviluppo piuttosto che di produzione.
Il debug significa che hai il debugger attivo e puoi fare debugging sul 
codice. Niente altro.

 Dove sbaglio?
come hai precisato, tomcat viene effettivamente riavviato, anche se lo fa 
eclipse per te ;-)
comunque sia testare l'applicazione col debugger attivo è diverso dal 
cambiare i parametri di configurazione per farla "puntare" a un ambiente 
piuttosto che a un altro o per aumentare il livello di logging.....

 Scusa ma non ho capito a livello pratico cosa dovrei fare.
Se usi un IDE (come Eclipse, mi pare di capire) allora imposta un ambiente
di testing affinché quando lanci debug (non run) ci siano parametri diversi
(es. il percorso di un file di proprietà invece di un altro). Se lo fai da
riga di comando l'idea non cambia: parametrizza la tua applicazione
affinché prenda la sua configurazione da un parametro di riga di comando,
che cambi a seconda della modalità di esecuzione.
Luca