FHIR Chat · Error loading package in java validator · implementers

Stream: implementers

Topic: Error loading package in java validator

view this post on Zulip Julian Sass (Mar 04 2021 at 15:05):

Hi, I encountered a problem with the java validator when validating against an ig package. It seems that one of the dependencies in the package does not resolve, although it is present in the registry and I'm relatively sure it was loading before. This is the package I'm using: http://registry.fhir.org/package/de.medizininformatikinitiative.kerndatensatz.diagnose|1.0.2
Here is the exception thrown by the validator:

  Load de.medizininformatikinitiative.kerndatensatz.meta#1.0.2 - 2 resources (00:00.0046)
  Load de.basisprofil.r4#0.9.12 - 126 resources (00:00.0355)
  Load KBV.Basis#1.1.0Exception in thread "main" org.hl7.fhir.exceptions.FHIRException: Unable to find/resolve/read -ig KBV.Basis#1.1.0
    at org.hl7.fhir.validation.IgLoader.loadIgSource(IgLoader.java:191)
    at org.hl7.fhir.validation.IgLoader.loadIg(IgLoader.java:85)
    at org.hl7.fhir.validation.IgLoader.loadIg(IgLoader.java:71)
    at org.hl7.fhir.validation.cli.services.ValidationService.getValidator(ValidationService.java:205)
    at org.hl7.fhir.validation.ValidatorCli.doValidation(ValidatorCli.java:200)
    at org.hl7.fhir.validation.ValidatorCli.main(ValidatorCli.java:156)

view this post on Zulip Lloyd McKenzie (Mar 04 2021 at 15:18):

@Mark Iantorno

view this post on Zulip Mark Iantorno (Mar 04 2021 at 19:35):

please provide the exact command you ran with any supporting files

view this post on Zulip Julian Sass (Mar 04 2021 at 20:12):

Mark Iantorno said:

please provide the exact command you ran with any supporting files

Here's the file and the command:
Condition-example.json de.medizininformatikinitiative.kerndatensatz.diagnose-1.0.2.tgz 

julian@Julians-MacBook-Air kerndatensatzmodul-diagnose % java -jar validator_cli.jar Condition-example.json -version 4.0 -ig de.medizininformatikinitiative.kerndatensatz.diagnose#1.0.2
FHIR Validation tool Version 5.3.2 (Git# 7e70adf8198d). Built 2021-02-18T23:33:17.184Z (13 days old)
  Java:   15.0.2 from /Library/Java/JavaVirtualMachines/jdk-15.0.2.jdk/Contents/Home on x86_64 (64bit). 2048MB available
  Paths:  Current = /Users/julian/git/kerndatensatzmodul-diagnose, Package Cache = /Users/julian/.fhir/packages
  Params: Condition-example.json -version 4.0 -ig de.medizininformatikinitiative.kerndatensatz.diagnose#1.0.2
Loading
  Load FHIR v4.0 from hl7.fhir.r4.core#4.0.1Creating Package manager?
 - 4575 resources (00:17.0543)
  Load hl7.terminology#2.0.0 - 3749 resources (00:01.0836)
  Terminology server http://tx.fhir.org - Version 1.9.369 (00:02.0909)
  Load de.medizininformatikinitiative.kerndatensatz.meta#1.0.2 - 2 resources (00:00.0101)
  Load de.basisprofil.r4#0.9.12 - 126 resources (00:01.0198)
  Load KBV.Basis#1.1.0Exception in thread "main" org.hl7.fhir.exceptions.FHIRException: Unable to find/resolve/read -ig KBV.Basis#1.1.0
    at org.hl7.fhir.validation.IgLoader.loadIgSource(IgLoader.java:191)
    at org.hl7.fhir.validation.IgLoader.loadIg(IgLoader.java:85)
    at org.hl7.fhir.validation.IgLoader.loadIg(IgLoader.java:71)
    at org.hl7.fhir.validation.cli.services.ValidationService.getValidator(ValidationService.java:205)
    at org.hl7.fhir.validation.ValidatorCli.doValidation(ValidatorCli.java:200)
    at org.hl7.fhir.validation.ValidatorCli.main(ValidatorCli.java:156)

view this post on Zulip Ward Weistra (Mar 31 2021 at 18:46):

@Julian Sass Given your comment here is this now resolved?

view this post on Zulip Julian Sass (Mar 31 2021 at 19:01):

Hi @Ward Weistra the error remains when packages include a dependency on KBV.Basis. But yes, resolved in the sense that the bug has been reported.

view this post on Zulip Ward Weistra (Mar 31 2021 at 19:14):

@Julian Sass Sorry to hear, I thought this was now resolved, given that the package API will now basically ignore capitalization (eg both https://packages.simplifier.net/KBV.Basis and https://packages.simplifier.net/kbv.basis resolve). But perhaps there's still some case-dependent resolving in the IG Publisher?
@Patrick Werner Is this also still occurring for you? And if so, is there a IG publisher ticket for that?

view this post on Zulip Martijn Harthoorn (Apr 08 2021 at 10:50):

Isn't this an issue with the upper cases in the package.json package reference?

view this post on Zulip Martijn Harthoorn (Apr 08 2021 at 10:50):

And the IG tool not being able to match that against the lower cased package listing?

view this post on Zulip Ward Weistra (Apr 09 2021 at 09:30):

@Patrick Werner @Grahame Grieve If this is still an issue, could the IG publisher be improved to compare package names case independent (always treat the names in package cache, dependencies, dependencies of dependencies as lowercase)?

view this post on Zulip Patrick Werner (Apr 09 2021 at 09:36):

Hey @Ward Weistra i hadn't had the time to fix this, and i think nobody else did it on the java side.

view this post on Zulip Patrick Werner (Apr 09 2021 at 09:36):

will file a ticket

view this post on Zulip Patrick Werner (Apr 11 2021 at 14:17):

https://github.com/hapifhir/org.hl7.fhir.core/issues/475
fyi: @Ward Weistra @Julian Sass @Grahame Grieve

view this post on Zulip Ward Weistra (Apr 13 2021 at 08:32):

@Chris Moesel :wait_one_second:️ FYI
Perhaps you can also check if sushi is comparing and searching for packages always as lowercase.

view this post on Zulip Ward Weistra (Apr 13 2021 at 09:09):

@Jens Villadsen Perhaps you can also check your scripts to make sure they always treat package names as lowercase, regardless of how provided.

view this post on Zulip Chris Moesel (Apr 13 2021 at 12:47):

@Ward Weistra -- I think we take the package name exactly as the user provided it in the config. If we switch to use lowercase only, then won't it temporarily break projects that currently depend on a Simplifier package name with capitals? Or am I misunderstanding?

view this post on Zulip Chris Moesel (Apr 13 2021 at 12:48):

That said, since Simplifier doesn't publish snapshots in the packages, I'm guessing we don't have too many cases of this anyway.

view this post on Zulip Ward Weistra (Apr 13 2021 at 14:10):

@Chris Moesel It depends a bit on how your logic for comparing packages is implemented. Let's take KBV.Basis 1.3.3 as an example:

When someone now specifies KBV.Basis@1.1.3 as a dependency in sushi or IG publisher or wherever, I hope you will:

  1. query the local package cache for kbv.basis regardless of how it's capitalized there
  2. if not locally available yet, query the package server for lowercase kbv.basis and put a lowercase folder in the FHIR package cache (although that shouldn't matter if other tools implement 1. as well, but just for good measure)

Makes sense or am I missing something?

view this post on Zulip Ward Weistra (Apr 13 2021 at 14:14):

We'll start to enforce new package( version)s to have lowercase names, possibly even update old ones to lowercase. But until other tools have capitalization-independent package comparison I'm afraid that will lead to breaking dependencies for current sushi/IG publisher IGs when using a previously capitalized dependency.

view this post on Zulip Chris Moesel (Apr 13 2021 at 15:04):

Thanks for the extra detail / suggested approach @Ward Weistra -- that's helpful. We'll look into this to ensure SUSHI fits within this.

view this post on Zulip Chris Moesel (Apr 13 2021 at 15:08):

SUSHI #800

view this post on Zulip Grahame Grieve (May 04 2021 at 03:02):

I can't reproduce this. it doesn't matter whether I use KBV.Basis or kbv.basis in the java client.

view this post on Zulip Ward Weistra (May 07 2021 at 08:01):

@Patrick Werner @Julian Sass Can you check whether this (https://github.com/hapifhir/org.hl7.fhir.core/issues/475) is still an issue and, if so, make it reproducible for Grahame?

view this post on Zulip Julian Sass (May 12 2021 at 11:31):

@Ward Weistra @Grahame Grieve Just tested again and I'm still getting this error with the java validator when I set the -ig parameter to de.medizininformatikinitiative.kerndatensatz.diagnose#1.0.2. This IG declares a dependency on "KBV.Basis": "1.1.0" in its package manifest. The subsequent version of diagnose changed this to kbv.basis and package loading works. Here's the log:

julian@Julians-Air kerndatensatzmodul-diagnose % java -jar validator_cli.jar Condition-example.json -version 4.0 -ig de.medizininformatikinitiative.kerndatensatz.diagnose#1.0.2
FHIR Validation tool Version 5.3.11 (Git# 33fffe28ff6b). Built 2021-04-22T05:48:36.375Z (20 days old)
  Java:   15.0.2 from /Library/Java/JavaVirtualMachines/jdk-15.0.2.jdk/Contents/Home on x86_64 (64bit). 2048MB available
  Paths:  Current = /Users/julian/git/kerndatensatzmodul-diagnose, Package Cache = /Users/julian/.fhir/packages
  Params: Condition-example.json -version 4.0 -ig de.medizininformatikinitiative.kerndatensatz.diagnose#1.0.2
Loading
  Load FHIR v4.0 from hl7.fhir.r4.core#4.0.1Creating Package manager?
 - 4575 resources (00:08.0710)
  Load hl7.terminology#2.0.0 - 3749 resources (00:02.0256)
  Terminology server http://tx.fhir.org - Version 1.9.372 (00:02.0206)
  Load de.medizininformatikinitiative.kerndatensatz.meta#1.0.2 - 2 resources (00:00.0028)
  Load de.basisprofil.r4#0.9.12 - 126 resources (00:00.0275)
  Load KBV.Basis#1.1.0Exception in thread "main" org.hl7.fhir.exceptions.FHIRException: Unable to find/resolve/read -ig KBV.Basis#1.1.0
    at org.hl7.fhir.validation.IgLoader.loadIgSource(IgLoader.java:195)
    at org.hl7.fhir.validation.IgLoader.loadIg(IgLoader.java:89)
    at org.hl7.fhir.validation.IgLoader.loadIg(IgLoader.java:75)
    at org.hl7.fhir.validation.cli.services.ValidationService.initializeValidator(ValidationService.java:234)
    at org.hl7.fhir.validation.cli.services.ValidationService.initializeValidator(ValidationService.java:212)
    at org.hl7.fhir.validation.ValidatorCli.doValidation(ValidatorCli.java:203)
    at org.hl7.fhir.validation.ValidatorCli.main(ValidatorCli.java:159)

view this post on Zulip Ward Weistra (May 12 2021 at 11:55):

Thanks @Julian Sass. @Kevin Mayfield sees the same here.
@Grahame Grieve Can you reproduce that for https://github.com/hapifhir/org.hl7.fhir.core/issues/475? I believe just always lowercasing any user inputted FHIR package names should do the trick.

view this post on Zulip Grahame Grieve (May 13 2021 at 22:46):

hah found it. It was an internal regex I was using for internal decision making. Should be fixed next release. Fixed next release

view this post on Zulip Morten Ernebjerg (May 27 2021 at 07:24):

It looks like I just encountered a separate version of this issue when trying to load packages into the JPA server starter, see this HAPI thread. Specifically, the JpaPackageCache#addPackageToCache method also does a package ID comparison that is case-sensitive (see these code lines), causing this error:

2021-05-26 16:52:02.948 [main] ERROR o.a.c.c.C.[Tomcat].[localhost].[/] [DirectJDKLog.java:175] Servlet.init() for servlet [jpaRestfulServer] threw exception
ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: Package ID KBV.Basis doesn't match expected: kbv.basis
    at ca.uhn.fhir.jpa.packages.JpaPackageCache.addPackageToCache(JpaPackageCache.java:199)

Am I right in assuming this would require a separate fix?

view this post on Zulip Morten Ernebjerg (May 27 2021 at 07:28):

(I'd be happy to do a PR for this, just wanted to check whether it would have further ramifications)

view this post on Zulip Grahame Grieve (May 27 2021 at 09:43):

yes you should do a PR for that

view this post on Zulip Morten Ernebjerg (May 27 2021 at 13:22):

Opened a PR with a fix that makes the ID check case-insensitive:

PR: https://github.com/hapifhir/hapi-fhir/pull/2683
Associated issue: https://github.com/hapifhir/hapi-fhir/issues/2682

Finally, I managed to (attempt to) contribute smt. to HAPI :smile: (even if it is only a single line & two tests...).

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -