How to configure parser error logging, etc.

[ru...@windofkeltia.com]

I am trying to tailor the verbosity of logging when parsing FHIR documents that have mistakes in them.

Yes, I can suppress logging absolutely by doing this in logback.xml:

  <logger name="ca.uhn.fhir" level="ERROR">

    <appender-ref ref="CONSOLE" />

  </logger>

However, I think I don't want to do that. I wondered why reducing error choking like this:

IParser parser = context.newXmlParser().setParserErrorHandler( new LenientErrorHandler().setErrorOnInvalidValue( false ) );

doesn't work when it appears to me throughout examples, actual code and documentation that it's possible. I see no difference in what comes out into the (unsuppressed) log with or without the call to method setParserErrorHandler().

Am I missing something?

Thanks for any comments!

[James Agnew]

What would be an example of a logging message you are trying to suppress?

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/13ac85c5-8324-4735-aa84-81ac7b43e0den%40googlegroups.com.

[ru...@windofkeltia.com]

Background

We take in millions upon millions of HL7v4 documents of various authorships. We are not authorities over the quality of those documents. All we do is index them. We use HAPI FHIR to analyze them and produce a sort of summary of the things that interest us in an index.

What we're thinking...

Sometimes, less frequent in FHIR as compared to nigh utter chaos in HL7v2 and HL7v3, we encounter errant construction. For example,

1230 [pool-1-thread-1] WARN  c.u.f.p.LenientErrorHandler.containedResourceWithNoId:69 - Resource has contained child resource with no ID

1232 [pool-1-thread-1] WARN  c.u.f.p.LenientErrorHandler.unknownElement:150 - Unknown element 'title' found while parsing

might show up. These don't kill the parser (I think only bad XML will do that), but they end up in our log which, under certain circumstances we do want to happen, but normally, this would tend to fill up the disk with notices of things not covered. So, in production, until trouble begins, we would rather suppress such entries.

What we thought the doc was telling us...

It's hard for me to make a convincing case for a cogent solution at this point. We're at the beginning of ingesting FHIR in earnest though we've flirted with it for years. For many years, we've ingested HL7v2, -v3, X12 and other formats. Here, I'm referring to documentation like

https://hapifhir.io/hapi-fhir/docs/validation/parser_error_handler.html

Talong my queue from that page, when I try to modify the error handler in use as suggested, set it to false, it does nothing that I can see.

IParser parser = context.newXmlParser().setParserErrorHandler( new LenientErrorHandler().setErrorOnInvalidValue( false ) );

I would like to substitute my own error handler if only to set breakpoints and begin understanding what trips what in situations like this. Ultimately, I probably don't wish to replace Lenient or Strict, but maybe I will and, despite what my brain reads in the documentation, that's not a real possibility. (Yet, why is it documented? What is my brain getting wrong?)

We're coding using JDK 11, creating Java 8-only code, consuming HAPI FHIR version 5.1.0 - Rev 6718826665.

Thanks for any thoughts.

[James Agnew]

Those lines are both controlled by the "theLogErrors" constructor parameter if you look into the source of LenientErrorHandler. If you're setting that to false, it should suppress them.

Might be worth attaching a debugger and putting a breakpoint in LenientErrorHandler to see what's going on.

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/5ce81627-7ba0-4b04-a16c-c1326b7bc8e7n%40googlegroups.com.

[ru...@windofkeltia.com]

Yes, I did that yesterday, the breakpoints were hit, I walked back up the stack looking around. I did see theLogErrors.  Maybe I didn't know what I was looking for. I find no way to affect the default Lenient. That's when I went looking for an alternative and thought that I had found it in the line of Java just above.

[James Agnew]

Possibly what's missing is for you to set your configured psarser error handler on the FhirContext. That way it will apply to all parsers that get created from it.

Cheers,

James

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/f7bb6f2a-41df-413b-8ff4-7d3f7e42e227n%40googlegroups.com.

[ru...@windofkeltia.com]

In fact, that was the first thing I tried because my XML and my JSON parsers derive from a single FHIR context (that's okay, right? tests for doing that have never so far failed me, but I don't know best practice). So, I only needed to do that code above once. Nevertheless, it didn't appear to work just as configuring the new parser doesn't appear to produce any behavioral change that I can notice.

[James Agnew]

Best practice is definitely to use 1 context to derive all of your parsers, clients, etc.

Unfortunately I'm not sure what to tell you about your actual issue. This definitely works as designed and skips those logs with the setting disabled, I just tried it. Maybe put breakpoints absolutely everywhere.. Parser constructors, fhircontext constructors, setters, etc... Something is off but I don't know what.

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/ee5b53a9-933c-4239-a642-beb9dba11fcen%40googlegroups.com.

[ru...@windofkeltia.com]

Yeah, I quickly did it again:

context.setParserErrorHandler( new LenientErrorHandler().setErrorOnInvalidValue( false ) );

Whence both my XML (I'm only caring about XML right now anyway) and JSON parsers are instantiated. I'm still getting the two log entries shown above.

Perhaps my expectations are off? Should swapping out the default Lenient for a new Lenient told not to "set error on invalid value" have silenced the log warning or not?

[ru...@windofkeltia.com]

Here's the answer. I needed to use Lenient's constructor argument and not merely the call to setErrorOnInvalidValue( false ):

context.setParserErrorHandler( new LenientErrorHandler( false ).setErrorOnInvalidValue( false ) );

This works, that is, this impedes the log warnings.