Upgrading HAPI on FHIR (part 2)

I'm still in the process of upgrading FHIR Microservices that have been developed using HAPI on FHIR 3.6 to HAPI on FHIR 4.0.  Earlier this week I shared my initial experiences, here's a few more.

Most of the subsequent challenges I've had are related to upgrading from Spring 1.5.6 to 2.1.1 and consequent changes updating my tracing libraries.

But I've found two tricky issues related to other components, one related to HL7 R4 classes and the Validator, and another related to uses of Embedded MongoDB for some of my testing.

Too many QNames

The first issue relates to uses of the XPP3 libraries that Grahame likes to use for efficient XML parsing.  The challenge here is that XPP3 is ancient and not being actively maintained.  Soooooo...
it exists before Oracle added javax.xml.namespace.QName to the Java Runtime library, and as a result, XPP3 rolled their own (actually, they copied it from an Apache Axis implementation) to support parsing.

The key problem for this is that the javax.xml.namespace is already defined in the JRE in a modular fashion, and so cannot be defined on the classpath when using a JRE after Java 8.  I'm using OpenJDK 11, so I'm affected.
I had a workaround which meant that I never really noticed this, because prior to Eclipse release 2019-06, you could have your JRE on your classpath, and it wouldn't cause a problem, but if you placed it in your imports modularly, then it would.

Having recently upgraded my Eclipse release to 2019-06, which no longer allows you switch the JRE libraries from the modules to classpath entries, I cannot work around the issue in local Eclipse builds.

The simple solution seems to be to strip the javax.xml.namespace.QName class from my downloaded XPP3 (1.1.4c) jar file, and use that instead of the usual one.  I'll probably rename it, put it into my local Maven repo with a patch, and exclude the dependency from my current build in favor of my patched version.  Hopefully, we can get it corrected in a slightly less hacky way (by getting whoever is currently interested in maintaining XPP to make the fix).

Updated: 10/11
James Agnew suggests using xpp3_min, which would address this problem.

Using Embedded MongoDB for Testing

The second problem I'm still digging into.  Since I've got some interest in testing locally and using MongoDB APIs for persistence, I want to be able to do testing with Embedded Mongo DB with my Spring Services.  Unfortunately, I'm still struggling with the upgrade for spring-data-mongodb and flapdoodle.  There's something somewhere that's changed that means that MongoDB no longer knows how to convert the data I'm working with.  I'll figure this one out eventually, but based on my research (StackOverflow and elsewhere), I'm not the first person to struggle with this challenge.

Updated 10/12
Finally figured this one out.  Some automatic configuration for MongoTemplate changed in Spring-Boot-Data after 1.5.6, and to simplify, I just added the collection names to my various calls to create/update/read/query/delete data, and the problem eventually disappeared.