Java/Maven - Saxon ohne SeviceLoader override

Question

Wir bauen eine gemeinsame Komponente auf, die eine Abhängigkeit für mehrere andere Projekte darstellt.

Unser Projekt führt einige XSLT-Transformationen durch und wir müssen die Saxon-Engine verwenden.

Wir haben die volle Kontrolle über die spezifische XSLT-Transformation, die Saxon verwenden muss, aber keine Kontrolle über den Klassenpfad der Anwendungen, die von uns abhängig sind, und wir möchten sie nicht zwingen, Saxon für andere XML-Arbeit zu verwenden.

Wir können die Saxon-Bibliothek manuell aufrufen, wenn wir unsere Transformationen mithilfe der von diesen Factories bereitgestellten API ausführen.

Das Problem ist, dass Saxon das ServiceLoader Muster verwendet, um sich als diese Datei in das Glas mit TransformerFactory Implementierung zu injizieren:

[saxon.jar]/META-INF/services/javax.xml.transform.TransformerFactory 

Dies bedeutet, dass Anwendungen, die uns als Abhängigkeit verwenden könnte sich mit der Sächsischen statt beenden ihrer vorhandenen XML-Bibliotheken. Diese Anwendungen zu bitten, ihren Code so zu ändern, dass sie ihre spezifische Implementierung aufrufen, ist keine Option.

Gibt es eine Möglichkeit, die sächsische Bibliothek zu 'überschreiben', um die Implementierung von ServiceLoader zu entfernen? Entweder mit Maven, Java oder einem anderen Prozess?

Answer 1

Beantworten Sie dies für zukünftige Entwickler mit dem gleichen Problem.

Wir konnten keinen Weg finden, dieses Problem zu lösen. Wir überlegten, ein Maven-Plugin zu schreiben, um die Datei META-INF/services/ aus dem JAR zu entfernen, aber letztendlich entschieden, dass dies keine angemessene Lösung war.

Wir befinden uns jetzt in der gleichen Position, in der wir begonnen haben - abhängige Anwendungen landen bei Saxon als registrierter Anbieter und überschreiben möglicherweise ihre bestehende Konfiguration.

Für die Anwendungen, die einen bestimmten XSLT-Prozessor verwenden müssen, haben wir sie gebeten, die Systemeigenschaft festzulegen, z. javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl

Answer 2

Leider ist es nur allzu üblich, dass Sie Bibliotheken finden, die den JAXP-Pluggability-Mechanismus verwenden, um den XSLT-Prozessor auf dem Klassenpfad aufzunehmen, der aber nur funktioniert, wenn dieser Prozessor Xalan ist.

Für das XPath-Szenario war dieses Problem so akut, dass sich der sächsische META-INF nicht mehr als XPath-Dienstanbieter ausgibt (obwohl er noch alle JAXP-Schnittstellen implementiert). Aber für XSLT wäre diese Lösung nicht akzeptabel.

Ich würde denken, dass in den meisten Situationen, das Setzen der Java-Systemeigenschaft javax.xml.transform.TransformerFactory auf den relevanten Klassennamen für Xalan sollte das Problem lösen.