ÉTAIT de 6,1 java.lang.Exception verifyerror: chargement de classe contrainte violée

L'environnement a ÉTÉ 6.1 sur Linux, le déploiement d'une application web qui utilise
les classes de xercesImpl.jar.

En raison de la politique de l'entreprise restrictions, l'application doit être déployée
paramètres:

Class Loader Order
    Classes loaded with parent class loader first
->  Classes loaded with application class loader first

WAR class loader policy
    Class loader for each WAR file in application
->  Single class loader for application

La GUERRE de fichier contient une copie de xercesImpl.jar, le même que celui que
a été dans le classpath de l'application compilée.

Lors du lancement de la webapp, quand le Printemps essaie d'analyser ses configs, il
jette:

java.lang.VerifyError: class loading constraint violated 
    (class: org/apache/xerces/jaxp/DocumentBuilderImpl 
    method: parse(Lorg/xml/sax/InputSource;)Lorg/w3c/dom/Document;)

ANALYSE DE LA MESURE

Il semble que c'ÉTAIT fournit une implémentation de
org.apache.xerces.jaxp.DocumentBuilderImpl, parce que nous pouvons l'enlever
xercesImpl.jar à partir de la GUERRE de fichier et obtiens toujours la même erreur (pas de
ClassNotFoundException). Ainsi a ÉTÉ semble être la résolution de l'références
à l'aide de sa propre copie qui est incompatible avec les références dans notre
compilé les fichiers de classe. Cependant, le seul autre exemple de "xercesImpl.jar'
Je peux trouver (autres que la copie déployé avec notre app) est dans le répertoire
deploytool, qui semble être en dehors de l'application serveur.

J'ai scanné tous les pots en ÉTÉ (tous les 1300 d'entre eux) avec

for i in `find . -name \*.jar`; do jar tvf $i|grep -qi xerces && echo $i ; done

et a constaté que ./java/jre/lib/xml.jar contient toutes les classes dans org.apache.xerces.*,
donc c'est probable, où le chargeur de classe est la résolution de la référence.

VOICI L'ÉTRANGE PARTIE:

Si nous changeons de "chargeur de classe parent en premier", nous ne voyons pas l'exception.
Cela va à l'encontre du comportement attendu. Nous nous attendons à ce que, avec
"l'application du chargeur de classe de première" elle serait d'utiliser la xercesImpl.jar que nous
à condition, et l'utilisation EST la version que si nous ensemble "chargeur de classe parent
d'abord". Cela semble être vers l'arrière à partir de ce que nous voyons réellement.

LA QUESTION:

Comment est le chargeur de classe délégation paramètre d'interagir avec les informations ci-dessus entraînera le comportement observé?

Cela sonne bien. Si je vous comprends, le problème n'est pas DocumentBuilderImpl, mais le fait qu'il est en train d'être résolu à partir du JDK alors que l'une des classes les références se retrouve dans la GUERRE. Cela n'explique pas pourquoi, lorsque nous incluons xercesImpl.jar dans la GUERRE, on obtient exactement la même erreur, citant la même méthode et les noms de classe. Dites-vous que la méthode et les noms de classe cité dans le message ne sont pas pertinents pour le problème?

OriginalL'auteur Jim Garrison | 2010-05-18

14

Votre GUERRE est également, y compris org.xml.sax ou org.le w3c.dom classes, et puis vous faites référence à une classe qui est à l'extérieur de votre application qui fait aussi référence à ces classes. Ceci définit un scénario où votre application chargeur de classe a de la visibilité à deux instances de la même classe, ce qui est un lien d'erreur.

Par exemple, si votre application utilise javax.xml.bind.Unmarshaller.unmarshal(InputSource), puis Unmarshaller serait chargé à partir du JDK, et la Unmarshaller classe a seulement une visibilité à la JDK InputSource. Lorsque votre application crée sa InputSource, il va charger la classe à partir de la GUERRE (parce que "la première application" de la politique), et, alors votre demande de tenter de passer une instance de la GUERRE InputSource le JDK Unmarshaller, qui ne peut accepter une instance de la JDK InputSource.

Il y a deux solutions:
1. Supprimer toutes les API pots à partir de votre application, et utiliser ceux du JDK. Par exemple, retirer le récipient contenant de l'org.xml.sax ou org.le w3c.dom.
2. Inclure toutes les bibliothèques dans la GUERRE qui référence les classes que vous souhaitez pour référence. Par exemple, inclure une copie de la JAXB bibliothèque dans votre GUERRE.
Dans mon expérience, le lien avec les erreurs sont assez difficiles à repérer car les machines virtuelles donner moche de l'information au sujet des causes des liens à ajouter. J'ai l'habitude de permettre chargeur de classe de trace, de reproduire le problème, et puis marcher à reculons jusqu'à ce que je trouve d'une classe chargée de l'extérieur de l'application qui "ressemble", il peut faire référence à une classe qui est connue pour exister à l'intérieur de l'application.

Cela sonne bien. Si je vous comprends, le problème n'est pas DocumentBuilderImpl, mais le fait qu'il est en train d'être résolu à partir du JDK alors que l'une des classes les références se retrouve dans la GUERRE. Cela n'explique pas pourquoi, lorsque nous incluons xercesImpl.jar dans la GUERRE, on obtient exactement la même erreur, citant la même méthode et les noms de classe. Dites-vous que la méthode et les noms de classe cité dans le message ne sont pas pertinents pour le problème?
Merci. Avec un peu de recherche, j'ai pu résoudre le problème en supprimant plusieurs inutiles pots à partir de notre application qui ont été laissés sur de avant le JDK inclus org.xml.sax et org.le w3c.dom. J'ai aussi trouvé un conflit définition de la source de données.
Oui, DocumentBuilderImpl est sans rapport avec le problème. La méthode parse arrive juste pour faire référence à des types qui ont des problèmes liés au couplage. Comme je l'ai dit, la JVM donne moche de l'information; j'aurais été plus audacieux et dit "et parfois trompeurs" :-).
Correctif pour mon cas: ajouter <champ>offre</> à maven de dépendance jaxb-api.

OriginalL'auteur Brett Kail

Notre problème était de déployer sur a ÉTÉ de 8,5.

Dans notre application web, nous avons un client de service web généré par cxf. Pas de questions.

Lorsque nous avons ajouté dans tika-analyseur pour le type mime de détection, puis nous avons eu ce problème.

Nous avons exclu les trois dépendances:

<dependency>
            <groupId>org.apache.tika</groupId>
            <artifactId>tika-parsers</artifactId>
            <version>${apache.tika.version}</version>
            <exclusions>
                <exclusion>
                    <artifactId>geronimo-stax-api_1.0_spec</artifactId>
                    <groupId>org.apache.geronimo.specs</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>xercesImpl</artifactId>
                    <groupId>xerces</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>xmlbeans</artifactId>
                    <groupId>org.apache.xmlbeans</groupId>
                </exclusion>
            </exclusions>
        </dependency>

Une fois qu'ils ont été exclus, notre application a démarré avec succès.

OriginalL'auteur shane lee

0

Il est peut-être trop tard mais, nous avons résolu ce problème, en supprimant cette ligne dans server.xml:

jaxb-2.1

OriginalL'auteur Eduardo Arcentales
-1

Désactiver le pseudo-code de Vérification

java.lang.Exception verifyerror - Runtime Décoché Exception
une fois le fichier de classe est chargé dans Websphere JVM, puis de byte code varification est le processus suivant.au cours de vérification du code octet si notre classe dans la violation de la JVM des contraintes ,ce message d'erreur s'affiche.

désactiver le bytecode de vérification. Aller à

admin console->serveur1->de java et de la gestion des processus->process definition->arguments JVM`

Et dans les arguments JVM passer à la chaîne suivante
```
 -Xverify:none 
```
et dans l'espace de travail ouvert le ApplicationDeploymentDescriptor fichier xml, allez à l'onglet déploiement, sélectionnez PARENT_LAST pour la guerre, ainsi que pour la première option. cela empêche le xml validations des erreurs.

OriginalL'auteur Neelam Chahal
-2

Si nous changeons de "chargeur de classe parent
première" nous ne voyons pas l'exception.
Cela va à l'encontre de l'attendre
comportement.

Oui, c'est correct, c'est la seule façon vous pouvez voir un tel comportement. Je peux vous suggérer yo prendre un coup d'oeil à la "voulez-vous vraiment obtenir de classe chargeurs?" de parler, comme il n'existe aucune réponse courte à votre question.

http://www.slideshare.net/guestd56374/do-you-really-get-class-loaders
http://www.parleys.com/#sl=2&st=5&id=1585

C'est vraiment plus d'une vente-terrain pour votre produit, non?
Oui, la réponse est correcte, "parent" dernier " est la seule façon de voir ce problème. Malheureusement, le lien n'est pas utile et a plusieurs inaccuraces. Diapositive 8: JavaEE spécifications mandat ni parent dernier, ni de séparer les CLs. Diapositive 11: ClassNoDefFoundException n'est pas un vrai type d'exception; la méthode est "getURLs". J'ai arrêté de regarder après. Fix et je vais supprimer downvote.
Hein? Il y a deux diapositives sur que dans l'intro. La conversation est spécifiquement sur la résolution des problèmes similaires. @bkail Pas que je me soucie de la façon dont vous votez, mais voir Servlet spec SRV.9.7.2. Merci pour les fautes de frappe, j'ai l'habitude de faire beaucoup de démos, de sorte que les diapositives ne sont pas terriblement important.

OriginalL'auteur Jevgeni Kabanov

Vous devez vous connecter pour publier un commentaire.

Désactiver le pseudo-code de Vérification