2012-02-27 9 views
14

Ricevo questa eccezione durante il tentativo di chiamare il servizio web SOAP utilizzando l'asse. in pratica ho scritto un client asse.conflitto di registrazione comune in conflitto con il client soap dell'asse Apache

org.apache.commons.discovery.DiscoveryException: Class org.apache.commons.logging.impl.SLF4JLogFactory does not implement org.apache.commons.logging.LogFactory. 

Quando rimuovo i tutti i vasetti common-logging, mi sarebbe in grado di rimuovere questi errori, ma questi vasi sono provenienti da altre API, io non avere il controllo su di essi.

C'è un modo per superare questo problema?

+0

Probabilmente la soluzione migliore è riportata di seguito. Ma se stai usando il progetto Maven, puoi rimuovere la registrazione comune per esclusione. asse asse 1,4 \t \t \t \t commons-logging \t \t \t commons-logging Purushothaman

risposta

9

C'è una spiegazione abbastanza dettagliata di ciò che può essere il problema e dei modi per eseguire il debug nello commons logging documentation. Il tuo problema particolare può essere,

C'è anche un altro modo più insolito in cui questo cast può fallire: anche quando il binario è compatibile, la classe di implementazione caricato in runtime può essere collegato ad una diversa istanza del Classe LogFactory. Per ulteriori informazioni, vedere tech guide.

6

il link al suddetto Documentation alla sezione "Correzioni" suggerisce di includere

-Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl 

nella configurazione. Per alcune persone potrebbe essere più facile per includere questo codice invece:

static 
{ 
    System.setProperty(LogFactory.FACTORY_PROPERTY, LogFactory.FACTORY_DEFAULT); 
} 
1

Nessuno di questa soluzione ha funzionato per me. Ho a capire la mia soluzione nella documentazione SLF4J

http://slf4j.org/faq.html#excludingJCL

alternativa 2) a condizione portata Commons-registrazione può essere piuttosto semplice e comodamente escluso come dipendenza dichiarandolo nel campo di applicazione previsto all'interno del pom. file xml del tuo progetto. Le effettive classi di registrazione delle commons verranno fornite da jcl-over-slf4j. Questo si traduce in il seguente frammento di file pom:

<dependency> 
    <groupId>commons-logging</groupId> 
    <artifactId>commons-logging</artifactId> 
    <version>1.1.1</version> 
    <scope>provided</scope> 
</dependency> 

<dependency> 
    <groupId>org.slf4j</groupId> 
    <artifactId>jcl-over-slf4j</artifactId> 
    <version>1.7.21</version> 
</dependency> 

La prima dichiarazione di dipendenza afferma in sostanza che commons-logging sarà "in qualche modo" fornito dal proprio ambiente. La seconda dichiarazione include jcl-over-slf4j nel progetto. Come jcl-over-slf4j è un sostituto perfetto compatibile con i binari per la registrazione delle commando , la prima asserzione diventa vera. Sfortunatamente, mentre si dichiara la registrazione delle commons nel campo di applicazione fornito, viene eseguito il lavoro , l'IDE, ad es. Eclipse, posizionerà commons-logging.jar su il percorso di classe del tuo progetto come visto dal tuo IDE. Dovresti rendere sicuro che jcl-over-slf4j.jar sia visibile prima di commons-logging.jar per il tuo IDE .

La documentazione di SLF4J offre più alternative, questo ha funzionato per me.