2013-11-26 18 views
14

Sto cercando di usare eclipse kepler per Java EE 7. Ho già installato JBoss Tools e ho aggiunto JBoss Wildfly come server. Tuttavia, le mie modifiche non vengono distribuite automaticamente. C'è comunque l'applicazione può essere distribuita automaticamente come quando si usa glassfish?Distribuzione hot di Eclipse Kepler e JBoss Wildfly

risposta

24

Utilizzo Eclipse, cliccare due volte sul tuo wildfly server per modificare le seguenti proprietà:

  1. Pubblicazione: scegliere "Pubblica automaticamente dopo un evento di compilazione". Mi piace cambiare anche l'intervallo di pubblicazione in 1 secondo.
  2. Applicazione Ricarica Comportamento: selezionare la casella di controllo "Personalizza reload applicazione ..." e modificare il modello di espressione regolare per \.jar$|\.class$

Questo è tutto. In bocca al lupo!

+2

+1, ma sfortunatamente la seconda opzione ha un serio svantaggio: lo stato di applicazione intero è perso. –

+0

Una cosa che ha funzionato per me: non distribuire come file compressi. Nelle proprietà di Eclipse Wildfly, NON selezionare l'opzione "Distribuisci progetti come archivi compressi" –

8

Suppongo che si stia utilizzando l'ultima versione di Wildfly (8.0 Beta 1 al momento della scrittura).

nel file di configurazione standalone.xml, cercare < jsp-config/>. Aggiungi l'attributo development = "true" e dovrebbe essere distribuito a caldo. La configurazione risultante sarà simile a questa:

<jsp-config development="true"/> 
+0

Ciao @Sean Ho fatto questo, ma quando ho cambiato un file di origine Java non noto le modifiche. Tuttavia se cambio un xhtml si riflette. – zulq

4

aggiungere attributi (lo sviluppo, il check-intervallo, la modifica-test-intervallo, ricompilare-on-fail) nel file di configurazione in XPath = // servlet-container/jsp- config/

<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only"> 
    <jsp-config development="true" check-interval="1" modification-test-interval="1" recompile-on-fail="true"/> 
</servlet-container> 

(funziona in WildFly-8.0.0.Final)

20

Sia @varantes che @Sean sono essenzialmente corretti, ma queste risposte non sono complete.

Sfortunatamente l'unico modo in un ambiente java server di disporre di una distribuzione completa a zero downtime consiste nell'utilizzare lo strumento JRebel o lo strumento spring-loaded gratuito.

Ma per progetti di piccole dimensioni ci sono alcuni modi per accelerare il lavoro con una distribuzione a caldo parziale. In sostanza: l'opzione

  1. Quando abilitato pubblicare automaticamente quando il cambiamento delle risorse cambia poi dentro *.html, *.xhtml file sono immediatamente riflesse non appena si aggiorna il browser.
  2. per rendere il lavoro di distribuzione a caldo per i file troppo *.jsp, allora si dovrebbe all'interno $ {wildfly-casa} /standalone/configuration/standalone.xml make seguente modifica:
    <jsp-config/>
    sostituirli con:
    <jsp-config development="true"/>

riavviare il server e godersi la distribuzione a caldo dei file Web.


Ma quando modifica *.java file sorgente, allora solo la distribuzione caldo parziale è possibile.
Come @varantes indicati nella sua risposta, consentendo Applicazione ricarica Comportamento con regex impostato \.jar$|\.class$ è un'opzione, ma ha grave inconveniente: intero modulo viene riavviato, quindi:

  1. occorre un certo tempo (a seconda su quanto è grande un modulo).
  2. Lo stato di intera applicazione è perso.

Quindi personalmente scoraggo questa soluzione.
JVM supporta (in modalità di debug) lo scambio di codice per i corpi dei metodi. Quindi, se stai modificando solo i corpi dei metodi esistenti, sei a casa (zero tempi di inattività, le modifiche si riflettono immediatamente). Ma devi disabilitare la pubblicazione automatica all'interno delle impostazioni del server, altrimenti lo stato dell'applicazione sarà comunque distrutto da quella ripubblicazione.

Ma se si sta pesantemente crafing codice Java (l'aggiunta di classi, annotazioni, costruttori) l'editoria poi sfortunatamente posso raccomandare solo impostare in Mai pubblicare automaticamente (o l'arresto server) e quando hai finito il tuo lavoro in file java, quindi riavviare a mano il modulo (o il server di accensione). Sta a te.


Funziona per piccoli progetti java, ma per quelli più grandi, JRebel è prezioso (o semplicemente molla), perché tutti gli approcci sopra descritti non sono sufficienti.
BTW: anche a causa di tali problemi, soluzioni come Rails/Django/Play! Framework hanno guadagnato così grande popolarità.

Buona fortuna e codifica veloce!

+0

Anche con Play! Quadro generale, se il progetto cresce di dimensioni decenti, incontrerai di nuovo gli stessi problemi. –

+0

@AntonArhipov Non capisco perché. Intendi problemi con la sostituzione a caldo del codice? Io non la penso così (anche se non ho mai visto un progetto Play così grande). O intendi solo una lunga startup? –

+0

In particolare, sostituzione del codice hot. Sono nel team JRebel (per la cronaca) e non abbiamo mai preso in considerazione l'implementazione del supporto di JRebel per quei fantasiosi framework. Ma ora gli utenti iniziano a chiedere informazioni sul supporto sempre di più: le applicazioni diventano grandi e il framework nativo che ricarica non tiene il passo. –

0

Avvia il server in modalità di debug e traccerà le probabilità all'interno dei metodi. Altre modifiche Chiederà di riavviare il server.