ServletException

Je prévois d’utiliser des servlets Java dans mon application. J’ai inclus les éléments suivants dans le fichier POM.xml de mon projet pour charger le fichier jar de mise en œuvre du servlet Java 3.0.

 org.glassfish javax.servlet 3.2-b05

Le projet se comstack bien. Cependant, quand je l’exécute, j’obtiens l’erreur suivante:

 java.lang.ClassFormatError: Absent Code atsortingbute in method that is not native or abstract in class file javax/servlet/ServletException

Je l’ai cherché ici et trouvé de bonnes réponses .

J’ai découvert d’eux que cette erreur se produit lorsque nous incluons le fichier JAR, qui ne contient que les interfaces définies par l’API servlet et non l’implémentation réelle. J’ai donc vérifié que le bocal Glassfish que j’utilise n’est que des interfaces ou qu’il contient également une implémentation. J’ai trouvé que c’est une implémentation et pas seulement des interfaces.

Alors maintenant, je me demande pourquoi je reçois cette erreur à l’exécution. N’importe qui?

METTRE À JOUR:

Tout à l’heure, j’ai découvert qu’il s’agissait d’une erreur flagrante de ma part (j’ajoutais le pot à un projet, alors que le projet était tout à fait différent!). Je suis désolé pour cela. L’ajout de l’implémentation du servlet glassfish résout le problème.

Merci Sandeep

Je me suis battu pendant environ 2 heures avec un problème lié aux dépendances javaee-api et javaee-web-api utilisées pour le plugin surefire. Comme les gars du forum JBoss ont gentiment posté il y a quelque temps , il apparaît que toute la bibliothèque JEE6 a été divisée (selon la décision Sun / Oracle) en un JAR API (interfaces / stubs uniquement) et les fournisseurs.

Comment cela est-il lié à cela? Si vous avez un problème avec la classe FacesContext , vous obtenez une erreur comme celle-ci:

 java.lang.ClassFormatError: Absent Code atsortingbute in method that is not native or abstract in class file javax/faces/context/FacesContext

Si vous examinez l’arborescence des dépendances, vous trouverez un fichier JAR d’API par défaut dans le chemin de classe de compilation, qui gêne également les problèmes d’exécution:

 javax.faces:javax.faces-api:jar:2.1:provided

L’ajout d’une exclusion explicite pour la configuration du plugin surefire imposera l’utilisation des dépendances JAR du fournisseur au moment du test:

  maven-surefire-plugin 2.12    javax.faces:javax.faces-api

J’espère que ça aide, ça a fonctionné pour moi.

J’ai échangé à glassfish-embedded-all et j’ai résolu ce problème.

   org.glassfish.main.extras glassfish-embedded-all 3.1.2.2 provided

  org.glassfish.main.extras glassfish-embedded-all 3.1.2.2 provided

Cela a fonctionné pour moi. Merci. Mais l’ordre dans pom.xml compte aussi pour moi

   javax javaee-api 6.0 provided   org.glassfish.main.extras glassfish-embedded-all 3.1.2.2 test

Au-dessus de l’ordre ne fonctionne pas

  org.glassfish.main.extras glassfish-embedded-all 3.1.2.2 test   javax javaee-api 6.0 provided

Ci-dessus

J’ai fait face à la même erreur en utilisant Jersey spécifiquement lorsque je lance mes tests (JUnit + Mockito). Ce qui fonctionne pour moi a été d’append le code ci-dessous à mon fichier pom.xml.

  com.sun.jersey jersey-test-framework 1.1.5.1 test

Note: J’utilise Jersey 1.17

J’ai récemment rencontré cette même erreur et, grâce à cette question et aux réponses ci-dessus – en particulier à leandro.freitos – j’ai pu résoudre le problème en utilisant

   org.glassfish.main.extras glassfish-embedded-all 3.1.2.2 provided

Il s’avère que le mien a à voir avec javax.servlet

J’avais un cas similaire à celui que josdem avait (même erreur, également lors de l’exécution de JUnit avec Mockito), mais sans Jersey. Alors, voici une solution indépendante de Jersey qui a fonctionné pour moi:

   org.apache.geronimo.specs geronimo-servlet_3.0_spec 1.0 test

Même problème ici. Bien que je sois devenu l’ordre dans lequel je déclarais des dépendances. La dépendance intégrée à glassfish doit être déclarée avant la dépendance javaee-web-api fournie.

   org.glassfish.extras glassfish-embedded-all 3.0 test   javax javaee-web-api 6.0 provided

Je ne suis pas sûr de savoir pourquoi le chemin de classe s’embrouille lorsque le logiciel glassfish embedded est placé après le javaee-web-api dans les tests. Je suppose que la machine virtuelle Java essaie de résoudre les classes javax dans le premier fourni, puis abandonne pendant les tests. J’imagine que déclarer la scope du test aurait préséance, mais cela ne semble pas être le cas dans ma situation. J’espère que cela aide quelqu’un.

a le même problème en compilant avec netbeans 7.2.1. Cependant, la sortie spécifiait un de mes propres fichiers source java comme ayant “un atsortingbut de code absent ……. etc”

En même temps, je pourrais comstackr et exécuter le même projet en utilisant JDeveloper. Après quelques “nettoyages” et redémarrages, les netbeans ont toujours créé le même problème.

J’ai finalement résolu le problème en ajoutant une méthode principale dans le fichier java, comme ayant “l’atsortingbut de code absent” et en utilisant celui-ci comme cible de débogage. Tous sont revenus à la normale.