Ich habe ein CXF / Hibernate / JBoss-basiertes Projekt geerbt, das den Dateinamen database.xsd enthält. Ich habe das Projekt durchgekämmt, um herauszufinden, welches Subsystem / Komponente im System database.xsd verwendet, aber nur eine Referenz in einer Datei, die vom maven-war-plugin verwendet wurde, um die WAR-Datei zu erstellen (webapp-cache.xml ).
Das deutet darauf hin, dass database.xsd ein Standard-Dateinamen ist, der von einem Framework oder Plugin erwartet wird. Aber was ist es? Überwintern? CXF? Andere?
Gibt es eine Dokumentation, die die Rolle von database.xsd im Paket, das darauf basiert, beschreibt?
UPDATE: Vorübergehendes Entfernen von database.xsd und Neuaufbauversuch führten zu zahlreichen Kompilierungsfehlern, die zu einem Prinzip XML2SQL.java -Datei mit einem Paket führten, auf das von *.hbm.xml DTO-Dateien verwiesen wurde. Das sagt mir, dass der Schuldige ... Ruhezustand ist!
Es ist Ruhezustand , weil das vorübergehende Entfernen von database.xsd und das erneute Erstellen zu zahlreichen Kompilierungsfehlern führte, die zu einem Prinzip XML2SQL.java -Datei mit einem Paket führten, auf das von *.hbm.xml DTO-Dateien nur . (siehe Update oben)
Ich würde dies dem "altmodischen Weg", "Gute Protokollierung" und "binäre Suche" nähern.
Zuerst in einer Testumgebung:
1) Stellen Sie sicher, dass Ihr Code für die Verwendung von log4j eingerichtet ist und die umfangreichste Protokollierungsstufe aktiviert ist.
2) Entnehmen Sie die Datenbank ".xsd" und ermitteln Sie grob den "Halb- punkt" des Fehlers. Zum Beispiel, sagen wir mit dem System-Setup richtig erzeugt es 1000 Zeilen der Protokollierung. Wenn die Datei "database.xsd" entfernt wurde, kann sie nicht geladen werden und hält nur 500 Protokollzeilen an. Betrachten Sie die Protokollierung und bestimmen Sie, welche Klassen / Methoden aufgerufen werden. (Eine andere Möglichkeit, damit zu arbeiten, anstatt die Datei database.xsd zu entfernen, besteht darin, eine Kopie mit Syntaxfehlern in Ihre Testumgebung einzufügen.)
3) Mit Ihrer Studie in Schritt 2 fügen Sie weitere Protokollierung und versuchen / Fänge, um mehr Informationen zu erfassen. Wenn dies nicht zulässt, können Sie das Ziel eingrenzen. Wiederholen Sie den Vorgang und konzentrieren Sie sich auf den Punkt "250 logging line". Fahren Sie damit fort, den Problembereich jedes Mal um die Hälfte zu reduzieren, bis Sie die Zielklassen gefunden haben.
Viele Java-Programme, die ich gesehen habe, codieren einfach den "glücklichen Pfad" und verlassen sich auf die Exception-Behandlung auf höchster Ebene, um Fehler zu erfassen und zu protokollieren, aber dies kann zu sehr dicken (sehr viele Zeilen) und schwer zu lesenden Dateien führen .