ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration nie można przesłać do org.apache.xerces.xni.parser.XMLParserConfiguration

Question

Zajmuję się tworzeniem aplikacji GWT w środowisku Eclipse i używam jdom2 do odczytywania niestandardowych plików właściwości xml.

Po ostatniej aktualizacji moja aplikacja kończy się niepowodzeniem z powyższym błędem podczas próby odczytania pliku xml. Odpowiedni ślad stosu jest:

org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration 
org.apache.xerces.parsers.SAXParser.<init>(Unknown Source) 
org.apache.xerces.parsers.SAXParser.<init>(Unknown Source) 
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source) 
org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source) 
org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) 
org.jdom2.input.sax.XMLReaders.createXMLReader(XMLReaders.java:165) 
org.jdom2.input.SAXBuilder.createParser(SAXBuilder.java:871) 
org.jdom2.input.SAXBuilder.buildEngine(SAXBuilder.java:854) 
org.jdom2.input.SAXBuilder.getEngine(SAXBuilder.java:904) 
org.jdom2.input.SAXBuilder.build(SAXBuilder.java:1116) 
uk.co.platosys.db.jdbc.DatabaseProperties.loadProperties(DatabaseProperties.java:78) 

bada ten problem sugeruje, że błąd może się pojawić, gdy niekompatybilne wersje Xerces słoików istnieje na ścieżce klasy.

gwt-dev-2.6.1.jar zawiera pakiety xerces, a moim przeczeniem jest to, że ta najnowsza wersja programu gwt-dev zawiera wersję, która jest niekompatybilna. Jednak obecne wydanie jdom2.0.5 zostało wydane wraz z wersją 2.11 Xerces, która wydaje się być najnowszą wersją wydaną przez Apache. Umieszczenie tych słoików na mojej ścieżce klas nie wydaje się rozwiązywać problemów; Wcześniej byłem w stanie polegać na wersjach w grze gwt-dev.

Jestem raczej na końcu mojego rozumu i znacznie poza moją strefą komfortu.

Answer 1

Kolejność słoików w kwestiach klasy Classpath. Czy próbowałeś dodać słoik Xerces 2.11 na początku ścieżki klas, aby najpierw był ładowany?

Answer 2

Nie walcz z Mavenem: jeśli rzeczy nie są używane razem, powinny wejść w oddzielne moduły. W twoim przypadku JDom jest (prawdopodobnie) używany po stronie serwera, który nie potrzebuje gwt-dev. Rozwiązaniem jest podzielenie twojego projektu na kilka modułów Maven: jeden dla klienta, który zależy od GWT, i jeden dla strony serwera, który tego nie robi (lub prawdopodobnie na servet-guście, jeśli używasz GWT-RPC, lub na requestfactory-server, jeśli używasz RequestFactory).

To powiedziawszy, nawet przy pojedynczym projekcie, jeśli masz gwt-dev w swojej ścieżce klasowej w czasie wykonywania, to masz coś nie tak w POM.

... chyba że czytasz pliki XML w czasie kompilacji?

Answer 3

W moim przypadku rozwiązałem ten problem, dodając do elementów bootstrap (karta Classpath w konfiguracji uruchamiania) dwa wpisy /xml-apis/xml-apis/1.4.01/xml-apis-1.4.01.jar i/xerces /xercesImpl/2.11.0/xercesImpl-2.11.0.jar z mojego lokalnego repozytorium maven

Answer 4

W moim przypadku zostało to rozwiązane poprzez usunięcie katalogu xerces w mojej lokalnej pamięci podręcznej sbt (lokalne repozytorium maven, jeśli używasz maven), oraz przebudowa projektu.

Answer 5

Miałem ten sam wyjątek, kiedy uaktualniłem swój projekt z GWT 2.7 do GWT 2.8. Nie mam pojęcia, dlaczego nie miałem tego problemu z GWT 2.7 (może inna pozycja w pliku .classpath projektu Eclipse może mieć na to wpływ).

Powodem tym wyjątkiem, że przed kod z takich jak:

DocumentBuilderFactory newInstance = DocumentBuilderFactory.newInstance(); 
DocumentBuilder newDocumentBuilder = newInstance.newDocumentBuilder(); 
baseLayoutXmlDocument = newDocumentBuilder.parse(baseLayoutSvgInputStream); 

SAXParserFactory spf = SAXParserFactory.newInstance(); 
SAXParser sp = spf.newSAXParser(); 

implementacje z JDK pakietu com.sun.org.apache.xerces.internal.jaxp wykorzystano, ale po aktualizacji do GWT2 .8 moja aplikacja wybrała xerces z pliku gwt-dev.jar. znalazłem poprawkę, że zgodnie z Javadoc i link here maszyn właściwości systemu

-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl 
-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl 

Answer 6

To jest trochę późno, ale po przeczytaniu odpowiedzi znalazłem jeden sposób, aby obejść ten problem.Zamiast budować fabrykę z normalną wersją DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();, możesz użyć parametrów w newInstance, aby wybrać konkretnie. W ten sposób nie musisz dodawać parametrów maszyny JVM, takich jak powyższa odpowiedź Svaroga, i nie musisz dodawać ani usuwać bibliotek. Moje rozwiązanie jest następujące:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance("com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl", this.getClass().getClassLoader()); 
DocumentBuilder builder = factory.newDocumentBuilder(); 
Document doc = builder.parse(new FileInputStream("path/to/file.xml"));