FHIR Chat · maven deps, projects and shading

Stream: hapi

Topic: maven deps, projects and shading

Jens Villadsen (Aug 17 2020 at 12:10):

Hi HAPI team - I've been puzzling with the hapi fhir starter project and I have a finding as well as a question for you guys @James Agnew & co:

1) I've made a PR (https://github.com/jvitrifork/hapi-fhir-jpaserver-starter/tree/spring-pr) that enables the use of spring boot as an example application that sets a spring profile based on the contents of the property file. Everything works like a charm when using the regular docker build scripts. However, when I start to debug the application (which was the entire purpose of doing this), I get runtime errors (caused by: java.lang.NoClassDefFoundError: org/apache/lucene/document/Field$Index) - probably because of the shading stuff that you are working on as well as mismatch betweeen lucene, ES and hibernate (what a dangerous cocktail). How should I proceed? It's reproducible as easy as cloning the branch backingt the PR and running the Application.java

2) You guys seem to maintain a spring boot project yourself at https://github.com/jamesagnew/hapi-fhir/tree/master/hapi-fhir-spring-boot. Why not merge the efforts instead of maintaining examples different places?

James Agnew (Aug 17 2020 at 12:42):

A couple of points here:

The shading is definitely a bad mix, but it's not intended to be a long term solution. We are in an annoying spot right now where the terminology services are written using Hibernate Search, which only supports ES 5, but we needed ES 6+ features in order to make $LastN support performant. Our hope was to use the lastn project to determine whether we were comfortable working without Hibernate Search entirely and at this point I'd say we are so we will likely stop using it in the future and just interact with ElasticSearch directly for all features. No timelines for this work yet, but it is definitely planned.
The Boot stuff is a 3rd party contribution, and unfortunately the contributor has not been able to maintain it. We don't use Boot at all so we don't have any insights into how to troubleshoot it. At this point, just keeping it passing the unit tests is a challenge- we'd welcome someone who wanted to put some love into it.

Jens Villadsen (Aug 17 2020 at 18:51):

Hmmmm .... okay. Well, another thing I needed to wrap my head around was the use of the new BulkExport job. From what I can see, all configurations extending/using the BaseConfig now needs to support or disable spring batch jobs because of https://github.com/jamesagnew/hapi-fhir/blob/1fadaeeff5872127d09253db96683e8078cdede9/hapi-fhir-jpaserver-base/src/main/java/ca/uhn/fhir/jpa/config/BaseConfig.java#L131

Would you consider adding spring profiles to the configuration as well? That would have eased the transition so that it would have been something that you actively needed to add.

James Agnew (Aug 18 2020 at 09:34):

What's the issue with batch jobs?

FWIW the jobs aren't new, and it wouldn't be good to run a server with them turned off. What's new is us using Spring Batch to run them (they were run using their own threadpools before).

I think in 5.1.0 you could get away with disabling Spring Batch and you'd just have a server where Bulk Export silently failed, but our aim is to move all of the server's long running processes into Spring Batch.

Jens Villadsen (Aug 18 2020 at 10:34):

The is no issue with Batch jobs in general, and I applaude the use of Spring Batch jobs. I was simply annoyed about the fact that Spring Boot started them without my intervention (which is not something you guys are hit by since you don't do Spring Boot). I also found that I could just disable them in the end, which is fine for 5.1.0, since only the BulkExport job uses it, which I do not currently use.