2009-02-11 5 views
5

Sono in esecuzione JBoss 4.0.3.SP1_CP04 e ci si collega con il debugger di Eclipse 3.4.1, entrambi con JDK 1.6.0_11.Come posso ottenere Java "hot code replacement" funzionante in JBoss?

Quando apporto una modifica minore a un metodo (ad esempio, modificando un "+ 1" nella logica in un "+ 2") e salvandolo, ricevo immediatamente una finestra di dialogo di messaggio di errore "Sostituzione codice non riuscita" con l'errore "metodo Delete non implementato"

Hot code replace failed dialog http://img6.imageshack.us/img6/531/hotcodereplacefailedkp6.png

qualcuno può suggerire passaggi per ottenere questo lavoro?

risposta

3

Quello che vuoi fare è distribuire su JBOSS come exploded WAR. In genere, se un editor esegue la distribuzione iniziale, gestirà la copia dei singoli file durante la loro modifica.

In IntelliJ, this is easy. Non l'ho mai fatto da Eclipse, ma lo this project è la soluzione migliore.

+0

Questa risposta mi ha ricordato di controllare se il mio WAR fosse esploso dopo aver creato un nuovo progetto e aver scoperto che non potevo scambiare a caldo - grazie! – peteorpeter

2

Ho utilizzato JRebel ed è un salvavita per quanto riguarda la modifica del codice e l'aggiornamento dinamico del server dell'app. Pagato per sé il primo giorno. (abbiamo un ciclo di compilazione/distribuzione/riavvio di 7 minuti)

0

Quello che hai descritto dovrebbe funzionare. Quali sono i tuoi argomenti di jvm su jboss per abilitare il debug?

Miniera sono questi: -Xdebug -Xnoagent -Xrunjdwp: trasporti = dt_socket, indirizzo = 8000, server = y, sospendere = n

0

Ho avuto un problema in cui la sostituzione del codice a caldo per sé non funzionava. Abbiamo apportato alcune modifiche, ad esempio assicurandoci che la "build automatically" fosse selezionata e deselezionando - "abort build quando si verifica un errore nel percorso di build". Ma nel mio caso, la stessa HCR non funzionava. Non stavo ricevendo il messaggio come hai detto. Maggiori dettagli sono in questo link. https://sites.google.com/site/javaerrorsandsolutions/home/hot-code-replacement

+0

Il collegamento è rotto. – palacsint

1
  1. Prima di eseguire debugger in Eclipse assicurare tutti i progetti nell'area di lavoro vengono aggiornati (è necessario se il codice è stato cambiato al di fuori di Eclipse, ad esempio dopo aver ricevuto le modifiche dal sistema di controllo di versione utilizzando lo strumento al di fuori)
  2. In Java Corporatura Path of Eclipse assicura che non includi come parte di alcune classi di libreria che stai cercando di scambiare a caldo
  3. Verifica che Eclipse JRE = JBoss JRE
  4. Controlla la classe che stai cercando di scambiare a caldo. Ha classi interne? Ho appena avuto problemi quando non riesco a scambiare la lezione con la classe interna, mentre le altre classi vengono scambiate senza problemi.
1

Il motivo è che l'assembly può essere utilizzato da un altro compilatore che hot swap. Ad esempio, se costruisci un progetto di Maven, abbiamo usato javac. Quando si tenta di eseguire uno scambio caldo, etslipse utilizza il compilatore jdt del compilatore incorporato (il compilatore non viene preso dal jdk installato e non può essere modificato con mezzi regolari). Le classi binarie ottenute sono diverse e jvm non può sostituirle.

+0

È possibile fornire una citazione che la JVM non può creare classi create dal compilatore interno di eclipse o quando vengono mescolate classi di compilatori diversi. Non riesco a immaginare perché dovrebbe essere così, ma non posso escluderlo. – dmeister

+2

Ho fatto l'esperienza che le normali classi di solito funzionano bene, ma non appena vengono coinvolte classi interne/anonime, le cose si rompono, penso che jdt e javac usino convenzioni di denominazione diverse per le classi generate. –