2013-05-10 12 views
5

È possibile utilizzare SLF4J in un'applicazione GlassFish specifica e configurare SLF4J esclusivamente per tale applicazione? Attualmente stiamo alle prese con il fatto che GlassFish stesso GlassFish con Hibernate installato contiene l'API SLF4J e un collegamento del registratore nella sua directory lib.Come posso utilizzare SLF4J per la mia applicazione web Java EE distribuita su GlassFish 3 con Hibernate JPA?

Il nostro team sta sviluppando un'applicazione web Java EE 6. Per lo sviluppo dell'applicazione è installato su GlassFish 3.1.2, tuttavia dovrebbe essere il più portabile possibile.

Abbiamo deciso di utilizzare SLF4J per registrare i messaggi dell'applicazione. A seconda del livello di messaggio, l'applicazione deve gestire determinati messaggi di registro in modo diverso e, quindi, deve essere in grado di configurare il back-end di registrazione da solo, anziché configurare la registrazione nel server delle applicazioni.

Purtroppo GlassFish 3.1.2 include slf4j-api-1.5.8.jar e slf4j-jdk14-1.5.8.jar nella sua cartella lib. Ciò impedisce alla nostra applicazione di utilizzare slf4j-api-1.7.5.jar e slf4j-simple-1.7.5.jar (quest'ultimo sarà sostituito da un altro binding alla fine).

C'è un modo per dire a GlassFish di considerare le lib di un'applicazione prima di considerarle proprie (in modo che venga utilizzata la versione corretta dell'API) e in che modo assicurarsi che l'applicazione abbia fornito il binding SLF4J?

Stiamo usando Eclipse per lo sviluppo ma siamo non utilizzando Maven. La maggior parte delle modifiche/soluzioni temporanee che ho trovato finora fanno riferimento alla configurazione di Maven che non è possibile utilizzare. Se puoi fornire suggerimenti specifici per Eclipse, sarebbe comunque ottimo. Nelle proprietà del progetto Eclipse ho già configurato l'ordine del percorso di build in modo che le librerie di app Web siano in primo piano. Ma in qualche modo questo non sembra essere abbastanza.

Mille grazie per il vostro aiuto!

Aggiornamento 1: Per farlo funzionare temporaneamente ho rimosso le librerie SLF4J dalla directory lib GlassFish. L'applicazione utilizza quindi le sue librerie SLF4J autonome. Ma non considero questa una soluzione per il processo di distribuzione, non sono sicuro che ciò potrebbe rompere qualsiasi cosa usata da GlassFish (perché le biblioteche dovrebbero comunque risiedere?), E questa non è una soluzione pratica per il nostro team di sviluppo.

Aggiornamento 2: In realtà è non GlassFish, che include la libreria SLF4J interferire out-of-the-box, ma il Hibernate JPA pacchetto ho installato tramite lo strumento di aggiornamento. Al momento non abbiamo bisogno di Hibernate JPA ma a un certo punto potrebbe sorgere il requisito di passare a Hibernate e vorremmo anche mantenere l'applicazione facilmente trasportabile sui server delle applicazioni con Hibernate JPA o altri pacchetti contenenti SLF4J installati. Ho aggiornato il titolo della domanda di conseguenza. Come può essere risolto questo problema generale delle dipendenze interferenti del server applicazioni e dell'applicazione?

risposta

1

Ciò è dovuto alla "Delegazione del caricatore di classe", provare a modificarlo in modo che tenga le classi dall'applicazione sopra le classi dal genitore.

Problemi correlati