How do I use mxparser in a modularized Java project?

[Lee Carver]

As I start to spin up the deserialization part of this project, I’m running into trouble getting the XML parsers to work.

When the XML load starts, the XStream system fails with an exception that offers these details

Caused by: org.xmlpull.v1.XmlPullParserException: caused by: org.xmlpull.v1.XmlPullParserException: resource not found: /META-INF/services/org.xmlpull.v1.XmlPullParserFactory make sure that parser implementing XmlPull API is available

Although this seems helpful, I’ve been unable to find a way to have the pull parser available in a JMPS application.  Simply adding explicit dependencies for the mxparser (and xmlpull) do not seem to do the trick

The application is structured around a modularized main application.  For serialization purposes, the code is structured as few Gradle projects:

 App project: full JPMS module
-> depends on
Persist project: automatic JPMS module
-> depends on
Xstream (implementation ‘com.thoughtworks.xstream:xstream:1.4.20’)

Just adding a dependency to the pull modules to either the Persist or App project did not seem to change the symptoms.

implementation 'io.github.x-stream:mxparser:1.2.2'
implementation 'xmlpull:xmlpull:1.1.3.1'

Since xmparser defines an Automatic-Module-Name, I tried adding that to the App project as a requires statement, but again, no change in the symptoms.

How do I make an implementation of the XmlPull API available to the XppDriver class during XML parser configuration?

[Jörg Schaible]

Hi Lee,

The XmlPull API uses Java SPI (actually a non-standard Java SPI anyway) to
locate available XML Pull parser implementations. However, with JPMS this
information must be present in the module-info of the Service Provider (and no
longer in META-INF/services) and also in declared in the Service Module, but
the XmlPull API does not contain something like this.

So for using the MXParser in a ModulePath, you will have to initialize XStream
explicitly with the MXParserDriver.

Regards,
Jörg

[Lee Carver]

Thank you for taking a look at this.  Despite careful engineering, other problems prevented the expected module access.

This problem arose due to the interaction between several of the build tools, and a now fixed bug in the JavaFX gradle plugin.  Upgrading to JavaFX gradle plugin version 0.1.0 [4-Sep-2023] solved this problem.

JavaFX gradle plugin: https://plugins.gradle.org/plugin/org.openjfx.javafxplugin

The DepanFX application combines JavaFX and XStream software components.  In JavaFX gradle plugin v0.0.14 [4-May-2023], the plugin erroneously alters the classpath and places the XStream components on the module path.  As a result, the XmlPull provider cannot be instantiated from the XmlPullParserFactory class.

This is fixed in JavaFX gradle plugin version 0.1.0.

Gory detail of this discovery are available here
https://leeca.hashnode.dev/dumpster-diving-practical-debugging-tactics 

[Jörg Schaible]

On Friday, 6th October 2023, 19:34:35 CEST Lee Carver wrote:
> Thank you for taking a look at this. Despite careful engineering, other
> problems prevented the expected module access.
>
> This problem arose due to the interaction between several of the build
> tools, and a now fixed bug in the JavaFX gradle plugin. Upgrading to
> JavaFX gradle plugin version 0.1.0 [4-Sep-2023] solved this problem.
>
> JavaFX gradle plugin:
> https://plugins.gradle.org/plugin/org.openjfx.javafxplugin
>
> The DepanFX application combines JavaFX and XStream software components.
> In JavaFX gradle plugin v0.0.14 [4-May-2023], the plugin erroneously
> alters the classpath and places the XStream components on the module path.
> As a result, the XmlPull provider cannot be instantiated from the
> XmlPullParserFactory class.
>
> This is fixed in JavaFX gradle plugin version 0.1.0.
>
> Gory detail of this discovery are available here
> https://leeca.hashnode.dev/dumpster-diving-practical-debugging-tactics

Thanks for this report and feedback.

Cheers,
Jörg