Classe Cast exception: com.soleil.org.apache.xerces.interne.jaxp.DocumentBuilderFactoryImpl
Je me suis heurté à un problème dans jboss. Lorsque j'essaie de déployer mon .la guerre dans le serveur, j'obtiens cette erreur suivante,
java.lang.ClassCastException: com.sun.org.apache.xerces.internal.jaxp.SAXParserF
actoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
à partir de laquelle, il est tout à fait évident qu'il y a un choc des bibliothèques. Donc, j'ai supprimé le fichier jar qui contient xerces, qui est passé par jaxp-ri-1.4.1.jar. Maintenant, quand j'essaie de re-déployer, je reçois cette nouvelle erreur,
java.lang.NullPointerException
at org.apache.commons.digester.Digester.getXMLReader(Digester.java:944)
at org.apache.commons.digester.Digester.parse(Digester.java:1765)
at org.apache.struts.action.ActionServlet.initServlet(ActionServlet.java
où il se plaint qu'il ne peut pas trouver les parseurs xml.
Donc, maintenant mes questions, c'est que quelqu'un sait ce qui peut être une solution. Tout jaxp fichier jar qui ne contient pas la xerces paquet?
Mise à jour
J'ai fait comme l'a suggéré ici et maintenant j'ai un nouveau message d'erreur,
java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
qui est une classe à partir de l'une des pots que j'ai supprimé qui contient SaxParserFactory 🙁
Toute information que nous pourrions avoir sur le nouveau supprimé POT?
OriginalL'auteur Ozyman | 2010-11-25
Vous devez vous connecter pour publier un commentaire.
Il semble que vous avez supprimé le mauvais POT. L'original ClassCastException a été signalé lors d'une instance de SAXParserFactoryImpl (qui est un sous-type de SAXParserFactory) est convertie en SAXParserFactory.
L'exception est plus susceptible d'être dû au fait qu'il y a deux instances de SAXParserFactory plutôt que deux instances de SAXParserFactoryImpl en cours de chargement dans la JVM. Au moment de la coulée, la SAXParserFactory chargé par un chargeur de classe a été renvoyé résultant de l'exception. Le correctif est donc d'identifier les Pots dans votre classpath qui ont des versions contradictoires SAXParserFactory. Retrait de l'analyseur de mise en œuvre elle-même peut ne pas être sage, si les Communes de l'Autoclave est à la recherche d'une mise en oeuvre particulière.
Je pense que ce serait une bonne idée de vérifier la façon dont vous avez hérité de ces Pots dans votre projet. Vous n'avez pas besoin d'une copie de jaxp-ri-1.4.1.jar ou jaxp-api.jar pour parser du XML, en particulier lorsque vous utilisez le JDK Sun. Le JDK/JRE utilise l'Api et de l'analyseur de mise en œuvre qui pourraient être utilisés. Au mieux, vous aurez besoin de la Xerces bibliothèque (avec seulement le nécessaire Pots), comme les Pots dans la distribution de l'origine de ce problème (xml-apis.jar en particulier à partir de Xerces 2.x).
Nous utiliser maven pour notre projet. Donc, il devrait être inclus. Surprise, il n'y est fait aucune mention de ces pots dans pom.xml trop. Notre projet est un projet de webservices projet, j'ai donc pensé que nous pourrions avoir besoin de leur regroupement. Je vais essayer et voir ce qui se passe quand je supprime jaxp-* les fichiers. Merci pour les conseils tout le chemin...
Ah, alors vous pourriez vouloir vérifier les dépendances sont tirés par Maven en raison de la webservice bibliothèques incluses. Je ne suis pas sûr si vous pouvez marquer la dépendances des dépendances d'exécution qui serait fournie par le conteneur, dans le POM. Si tout le reste échoue, envisager de dissocier vos webservices de l'Struts actions, éventuellement dans un autre module web.
OriginalL'auteur Vineet Reynolds
Je devine... Vous êtes à l'aide de JBoss 5.1. Si oui, alors c'est l'analyseur xml et classloading question. Vous devez définir jboss-classloading.xml
Voir http://www.coderanch.com/t/523519/JBoss/Cast et http://www.mastertheboss.com/jboss-application-ser...oss-5-classloading-issues.html
Encore une chose: à l'aide de jboss-classloading.xml est simple et nous permet de résoudre nos problèmes très rapide, mais il est parfois nécessaire d'analyser notre demande plus de soin. Nous devons nous assurer qu'il ne s'agit pas de libs/classe copnflict. Il n'est pas facile, mais si nous ne le faisons pas, nous risquons de tomber dans l'ennui. Classloading problèmes provoquer veeeery des erreurs étranges. Par exemple. dans mon cas, j'ai été en mesure de déployer mon application comme éclatée de la guerre, mais pas comme étant archivée de la guerre. Ce qui s'est avéré être une solution? La suppression jboss-classloading.xml et certaines libs 🙂
OriginalL'auteur patrycja