2009-08-10 15 views
14

Mam aplikację, która działa szczęśliwie w Javie 1.5 przez około rok. Właśnie zaktualizowaliśmy pudełka i zainstalowaliśmy Javę 1.6.Metoda Java działa w wersji 1.5, ale nie 1.6

Po wdrożeniu aplikacji na nowym serwerze okazało się, że aplikacja rzuca wyjątek podczas próby przekształcenia niektórych plików XML. Nie mogliśmy zrozumieć, dlaczego tak się dzieje, dopóki nie wdrożyliśmy go lokalnie i tak samo się stało. Po zmianie zestawu SDK na wersję 1.5 problem został zatrzymany, a aplikacja działa poprawnie.

Tutaj jest metoda za źródło:

import java.io.StringWriter; 
import javax.xml.transform.Result; 
import javax.xml.transform.Source; 
import javax.xml.transform.Transformer; 
import javax.xml.transform.TransformerConfigurationException; 
import javax.xml.transform.TransformerException; 
import javax.xml.transform.TransformerFactory; 
import javax.xml.transform.dom.DOMSource; 
import javax.xml.transform.stream.StreamResult; 

import org.w3c.dom.Element; 
import org.w3c.dom.Node; 


    public static String xmlToString(Node node) { 
    try { 
     Source source = new DOMSource(node); 
     StringWriter stringWriter = new StringWriter(); 
     Result result = new StreamResult(stringWriter); 
     TransformerFactory factory = TransformerFactory.newInstance(); 
     Transformer transformer = factory.newTransformer(); 
     transformer.transform(source, result); 
     return stringWriter.getBuffer().toString(); 
    } catch (TransformerConfigurationException e) { 
     e.printStackTrace(); 
    } catch (TransformerException e) { 
     e.printStackTrace(); 
    } 
    return null; 
    } 

To upaść na "transformer.transform (źródło, wynik);" z wyjątkiem:

Exception in thread "main" java.lang.AbstractMethodError: org.apache.xerces.dom.DocumentImpl.getXmlStandalone()Z 
    at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.setDocumentInfo(DOM2TO.java:373) 
    at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:127) 
    at com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:94) 
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:662) 
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:708) 
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313) 

Czy ktoś wie o jakichkolwiek zmianach dokonanych w Javie między dwiema wersjami, które by to spowodowały? Jaka byłaby najłatwiejsza naprawa?

Dzięki za pomoc.

+4

Wygląda na to, że w ścieżce klasy występuje sprzeczna implementacja Xerxes. – akarnokd

+1

Jakie słoiki związane z xml znajdują się w ścieżce klas? – Yishai

Odpowiedz

18

nie pamiętam, czy to pomiędzy 1.4 i 1.5 lub 1.5 i 1.6, ale biblioteki XALAN dostarczone z JVM od Sun zmienił nazwę pakietu. Wpadłem na coś podobnego około 2 lata temu. Myślę, że to, co musiałem zrobić, to jednoznacznie wysłać moją własną implementację xalan, aby naprawić problem.

UPDATE: To mogło być to, co miał na myśli, choć nadal mogłyby być związane z problemem link text

+7

Powinieneś używać tylko interfejsu JAXP API lub polegać na bibliotekach xerces, nigdy na dostarczonej przez nas implementacji (która będzie się różnić w zależności od wersji). – wds

+1

Widzę przypadek, w którym tak się dzieje i kod wywołuje TransformerFactory, aby utworzyć transformator, a następnie transform() na transformatorze i rzuca ten wyjątek. Wydaje się, że jest to właściwy sposób. Kod działał poprawnie w Javie 5 i po aktualizacji do wersji 6 Java rzuca ten wyjątek. Włączenie mojej własnej kopii xalana naprawiło problem. –

+0

gdzie mogę znaleźć własną kopię xalan? i jak dołączyć i wymienić to, co otrzymałem od oracle? –

3

Jest to problem, ponieważ słoik (Xalan) konfliktu wersji. Wyjąć słoiki i spróbować

+0

Próbowałem dodać nowy XARces JAR, ale to nie rozwiązało jak w górnej części przegłosowanej odpowiedzi, więc spróbowałem twojej sugestii i usunąłem XARces JAR z mojej ścieżki budowania i działało, dziękuję! – Kairan

+0

XALAN wchodzi w rt.jar Czy chcesz usunąć słoik ze ścieżki jre/lib? –

0

Możesz używać najnowszej wersji z Xerces (wierzę powinno być compitable z JDK1.6)

7

Problem ten jest znany z występowania na JDK 1.6 ze starszych Xerces. słoik, który w ścieżce klas udostępnia własny DocumentBuilderFactory.

Problem nie występuje podczas korzystania z domyślnej fabryki platformy.

Możesz chcieć sprawdzić swoją WEB-INF/lib lub odpowiednik.

2

Występuje w moim kodzie ten sam java.lang.AbstractMethodError.

W czasie zmieniającym wersję jakichkolwiek bibliotek nie było opcji, ale znalazłem obejście poprzez porównanie z innym kodem, który w tajemniczy sposób pracował. Być może może to pomóc innym.

Wszystko to miało związek z Dokumentem, który przekazałem do DOMSource(). Pierwotnie I stworzył dokument w standardowy sposób:

private static Document documentFromInputStream(InputStream in) throws ParserConfigurationException, SAXException, IOException { 
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 
    DocumentBuilder builder = factory.newDocumentBuilder(); 
    Document doc = builder.parse(new InputSource(in)); 
    return doc; 
} 

Aby obejść ten problem, zmienić linię fabryczną następująco:

 DocumentBuilderFactory factory = new DocumentBuilderFactoryImpl(); 

Teraz już nie dostać wyjątek .

+0

Świetnie! nie musisz zajmować się konfliktem słoików. Dziękuję Ci. –

0

miałem ten sam problem & zastąpił xercesImpl-2.0.2.plik jar z xercesImpl-2.11.0.jar na ścieżce klas mojej aplikacji. Działa dobrze.

0

To zadziałało dla mnie.

TransformerFactory factory = TransformerFactory.newInstance(); 
    Transformer transformer = factory.newTransformer(); 
      transformer.setOutputProperty(OutputKeys.METHOD, "xml"); 
    DOMSource source = new DOMSource(doc); 
      StreamResult result = new StreamResult(sWout); 
      transformer.transform(source, result); 
Powiązane problemy