2015-07-16 13 views
8

Nella riproduzione 2.4, l'override del metodo builder in ApplicationLoader o l'implementazione di EagerBinding nel modulo Abstract sostituisce la riproduzione esistente 2.3 GlobalSettings onStart.PlayFramework 2.4 esegue un codice dopo l'avvio dell'applicazione

Tuttavia nel gioco 2.3 il metodo onStart, l'applicazione è già stata avviata con tutti i plugin/dipendenze caricati. Puoi fare lo stesso nel gioco 2.4, cioè eseguire un pezzo di codice dopo l'avvio dell'applicazione.

Nella mia situazione, Slick richiede che l'applicazione sia avviata prima che possa accedere al database.

Grazie

risposta

0

Roy, il problema non è stato risolto.

Avete riscontrato un problema con l'utilizzo di un oggetto EagerBinding come si menziona?

È ancora possibile utilizzare GlobalSettings onStart, beforeStart etc se lo si desidera, è solo scoraggiato a causa del desiderio di allontanarsi dallo stato globale.

+1

Ciao, grazie per la risposta. Sì, puoi ancora utilizzare GlobalSettings su Start, ma dal momento che è deprecato e verrà rimosso in futuro, non desidero continuare a utilizzarlo. Il problema che sto affrontando è che slick richiede un'applicazione in esecuzione prima che possa interrogare il database (ad esempio, deve essere stata chiamata Play.start (app)). Usando EagerBindings, posso eseguire un'attività prima che l'applicazione sia iniziata ma non dopo. Cheers –

6

È risaputo che quando si associa una classe con entusiasmo in un Module, si cercherà di inizializzare un'istanza al più presto possibile. Nel framework di gioco 2.4 questo è come si ottiene il codice di esecuzione prima dell'avvio dell'applicazione.

Ma seguenti regole attesi comuni di DI: Se, nel costruttore della classe che si desidera eseguire, si aggiunge come parametro (alias "una dipendenza") per app: Application poi sarà eseguito dopo l'applicazione è iniziato; in questo modo:

import play.api.Application 
import javax.inject.Inject 

class MyInitCodeClass @Inject() (val app: Application) { 

//YOUR CODE HERE 

} 

Ciò è logico come qualsiasi quadro DI degno funzionerà cui le classi si può iniettare in quale ordine.

Poi, nel modulo è sufficiente aggiungere il solito vincolante (qui lo stile play framework invece di Guice):

bind[MyInitCodeClass] toSelf eagerly() 

Spero che questo funziona. È anche utile smettere di usare Play.current e iniettare l'app usando il nuovo sistema DI di Play 2.4.

Mi piacerebbe dare crediti a @easel su playframework gitter room per avermi aiutato con quello.

+1

è così ad hoc – caeus

+0

Hey, grazie per la tua risposta, sembrava molto buono, ma in realtà non ho avuto il tempo di provarlo fino ad ora. Potevo legare l'applicazione a questo, ma lo stato dell'applicazione non era ancora iniziato prima dell'esecuzione del codice. Ho anche provato a iniziarlo da solo facendo "Play.start (app)", che non è l'ideale e che ha causato alcuni problemi nella produzione. –

+0

Questo dà ancora lo stesso errore in gioco 2.4.2 – arpad