0
votes

JMeter ne peut pas lire les dépendances personnalisées

J'ai écrit une application maven que je souhaite utiliser dans mon script JMeter BeanShell. L'application Maven utilise Google Guice 4.2.2 Code> pour une injection de dépendonnée et il appelle une API à la fin (le code doit effectuer d'autres opérations avant d'appeler l'API et c'est pourquoi je n'utilise pas le JMeter Brancher). Je crée le jar uber strong> (gros pot) avec maven-shade-plugin code>. Lorsque j'exécute le pot à partir de la ligne de commande, l'application exécutoire avec succès!

Cependant, lorsque je charge le bocal dans mon plan de test JMeter et appelez ma méthode principale d'application dans le jmètre BeanShell, je reçois l'erreur suivante: P >

java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;Ljava/lang/Object;)V
    at com.google.inject.Key.ensureRetainedAtRuntime(Key.java:341) ~[load-testing.jar:?]
    .
    .
    .


1 commentaires

Je pense que j'ai trouvé le problème. Je pense que ma goyave est conflictuelle avec la version JMeter Guava. Je viens de télécharger le Apachejmeter_core V5.1.1 et l'observation de la THTA, il exploite une version 17.0 GUAVA qui peut généralement provoquer cette exception. La version GUAVA devrait être généralement 20.0.x>


3 Réponses :


0
votes

Il semble que votre fat-bocal contienne plusieurs versions de GUAVA (pouvant être causées par le plug-in de la nuance).

Assurez-vous de le verrouiller à une seule version à l'aide de la gestion de la dépendance de MAVENS dans chaque module maven. ( https://maven.apache.org/guides /introduction/introduction-to-dependency-mechanism.html#dependency_management )


1 commentaires

Je ne suis pas sûr de cela parce que lorsque j'exécute le pot du terminal, il réussit. Un autre test que j'effectue placer était un pot dans une simple application Maven et appelez ma classe principale qui a également réussi



0
votes

Le Beanshell lui-même pourrait être un problème, Depuis JMeter 3.1 Il est recommandé d'utiliser JSR223 Eléments de test et langue groovy pour script , les raisons sont dans:

  • Groovy est plus "moderne" langage qui prend en charge toutes les fonctionnalités de Java modernes avec BeanShell, vous êtes coincé à Java 1.5 Niveau de langue (pas de Lambdas, pas de génériques, pas de multi-captures, etc.)
  • La performance groovy est beaucoup mieux comparant à BeanShell Cause Grooovy Moteur Implements Compilable interface et est capable de mettre en cache des scripts compilés offrant des performances très proches du code Java natif
  • groovy fournit Beaucoup d'améliorations sur le haut de la norme Java SDK

    Vérifiez Apache Groovy - Pourquoi et comment vous devez l'utiliser article pour plus de détails.


1 commentaires

Merci pour l'information, j'ai déjà testé cela avec le JSR233 et Groovy 2.4.16, mais un même problème se produit



0
votes

J'ai enfin cofirmé mon commentaire. Le problème était que ma version jar Guava était en conflit avec JMeter Guava version (qui est 17.0) et JMeter pour une raison quelconque est une raison pour une autre version de goyave, après la rétrogradation de la version Guice à 3.0 qui ne dépend pas de GUAVA , J'ai dirigé avec succès mon pot à travers JMeter.

Il y a encore un mystère sur la raison pour laquelle Jmeter est en train de remplacer la version de ma Jar Guava. Je vais créer un billet avec JMeter afin d'en trouver plus sur ce mystère, mais ce changement a résolu mon problème


0 commentaires