Erreur java.lang.NoSuchMethodError inexplicable

Version imprimable

26/03/2014, 10h39
hn2k5

Erreur java.lang.NoSuchMethodError inexplicable

Bonjour,

Je développe un jar destiné à être utilisé par une application d'un client.
Ce jar est généré à l'aide de scripts ant plutôt rodés qui tournent depuis pas mal de temps donc de ce côté là il me semble que rien ne cloche.
Le jar est incorporé dans une publication que l'on ouvrira avec l'application du client. Ces publications sont générés sur un serveur dédié, donc nous récupérons tous la même version du jar.
Sur ma machine (windows 7) survient systématiquement une java.lang.NoSuchMethodError. Quand je décompile le jar en question, je m'aperçois que la méthode est bien là.
Sur les machines autres que la mienne, aucun problème de méthode manquante. Tout fonctionne normalement.

J'ai donc :
- vidé le cache java : sans succès
- désactivé le cache java : sans succès
- supprimé (1.6.0_31) puis réinstallé java (1.6.0_20) : sans succès
- vidé un peu tous les répertoires temporaires que j'ai trouvé dans windows et dans mon compte utilisateur : sans succès
- rétablir les options par défaut des paramètres des fichiers temporaires dans les options java : sans succès.

Je suis à deux doigts de contacter un exorciste. Je cherche une explication à ce comportement étrange mais là j'ai vraiment fait le tour de ce que je connaissais.
Y a-t-il une manip que je puisse faire en manuel pour être sûr de n'avoir plus aucun cache java ?
J'ai fouiné dans le répertoire par défaut du cache java : C:\Users\{user}\AppData\LocalLow\Sun\Java\Deployment\cache.
Là se trouvent des répertoires : "0", "1", "2", "3", ..., 63, host, muffin, splash. Ceux-ci sont bel et bien vides après nettoyage du cache dans les options.
Je cherche éventuellement un moyen de changer l'emplacement des fichiers temporaires java mais le bouton "Modifier..." est désactivé.

Merci d'avance pour votre aide et bonne journée.
26/03/2014, 10h44
adiGuba

Salut,

Quel est le stacktrace complet de l’exception ?
De quelle méthode s'agit-il ?

a++

Alors je maîtrise pas tout le processus d'appel de la méthode étant donné que le jar est utilisé par l'application au travers de ces fameuses publications.
Voilà ce que j'ai comme stack trace, j'ai masqué qqs packages pour ne pas violer d'éventuelles clauses de confidentialité.
Lorsque je décompile mon jar, je vois bien que ma classe ExhaustiveSearchServiceResponse contient le membre customer (String) ainsi que ses accesseurs getCustomer et setCustomer.
Ce qui me tarabuste le plus, c'est que ce phénomène survient uniquement sur ma machine et pourtant nous utilisons tous la même publication (donc le même jar).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
java.lang.NoSuchMethodError: com.[...].plugin.ips.common.service.ExhaustiveSearchServiceResponse.setCustomer(Ljava/lang/String;)V
	at com.[...].plugin.ips.server.service.ExhaustiveSearchExecutorServer.setReponse(Unknown Source)
	at com.[...].plugin.ips.server.service.ExhaustiveSearchExecutorServer.getPubliParameters(Unknown Source)
	at com.[...].plugin.ips.server.service.ExhaustiveSearchExecutorServer.execute(Unknown Source)
	at com.[...].server.manager.service.CommunicationServiceWrapper.invoke(Unknown Source)
	at com.[...].connection.ServerConnectionManager.handleRequestFromPlugin(Unknown Source)
	at com.[...].connection.ServerActionDispatcher.doRequestFromPlugin(Unknown Source)
	at com.[...].server.servlet.ServerActionDispatcher.doRequestFromPlugin(Unknown Source)
	at com.[...].connection.ServerActionDispatcher.dispatch(Unknown Source)
	at com.[...].connection.ServerActionDispatcher.doPost(Unknown Source)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
	at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Unknown Source)

Cdlmt

26/03/2014, 11h28
adiGuba
Tu peux afficher la liste des méthodes de cette classe :
Code:

1 2 3 for (Method m : ExhaustiveSearchServiceResponse.class.getMethods()) { System.out.println(m); }
L'application comporte-t-elle plusieurs jar ? Vérifie bien que la classe ne soit pas défini deux fois...

a++
26/03/2014, 11h59
hn2k5

L'application utilise en effet plusieurs jar (c'est le moins que l'on puisse dire), c'est une méchante usine à gaz que nous paramétrons dans nos publications.
Elle utilise en fait de nombreuses librairies qu'elle intègre elle-même mais également des jar contenus dans nos publications.
Je vais tenter une désinstallation complète de l'application puis réinstallation et après ça, si ça ne marche toujours pas, je refilerai le bébé.
:-)
Merci pour ton aide en tout cas.
26/03/2014, 12h15
tchize_

La cause la plus probable que je connaisse effectivement de ce comportement (méthode absente seulement sur certaines jvm / os) c'est d'avoir la classe en double. Comme il n'y a pas de règle précise sur l'ordre dans lequel les jar sont chargés, sur ton os, il est probable que le "mauvais" jar soit chargé en premier, du coup la mauvaise version de la classe est chargées, du coup la méthode n'existe pas. Sur une machine linux, prendre l'ensemble des jar constituant et faire un

grep plugin.ips.common.service.ExhaustiveSearchServiceResponse *.jar

permet déjà de dégrossir rapidement le problème.

Deuxième possibilité encore plus chiante, le script ant a une erreur et inclue deux version de la classe dans le même jar => Ca devrait se voir rapidement avec winzip. Fondamentalement pour la jvm c'est le même problème: quel .class prendre ? :)

aussi, tu déclare en décompilant le jar que la méthode est là. Elle a bien exactement la bonne signature:

Code:

void setCustomer(String arg0)

? Souvent en vérifiant, on oublie de vérifier le type de retour dans la signature :)
26/03/2014, 13h56
hn2k5

Tout d'abord merci pour votre aide. J'ai finalement désinstallé puis réinstallé l'application en question et le problème a disparu.
Je pense que l'application devait avoir un cache perdu qq part ailleurs que dans le répertoire habituel (peut-être à cause d'un crash ou d'un arrêt inopiné du serveur).
Je mets le sujet à résolu mais je doute que ça serve à beaucoup de monde... Sauf peut-être à mes collègues.
;-)

Merci et bonne journée.