Announcement

Collapse
No announcement yet.

Apparent Class Conflict with Custom Resource Library - Solved

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Apparent Class Conflict with Custom Resource Library - Solved

    We recently did an upgrade from v3.10 to v3.12 and Mirth went completely wonky due to what appears to be a class conflict. We ultimately resolved the issue (details below) but I wanted to post here and to the github forum about what happened in case it is helpful to someone else. I certainly wasn't able to find any posts about this scenario and it has the potential to be a huge headache and cause downtime.

    We utilize a nifty library called Docx4j to create, edit and manipulate MS Word and Excel files. Due to the nature of open source projects, you can imagine that there are many packages/jars in common between Mirth and Docx4j. We had not encountered any conflicts until this upgrade, so whatever changed in Mirth occurred sometime after v3.10. In version 3.12, two jars in the Docx4j dependencies caused problems:
    • xalan-interpretive-8.0.0.jar
    • xalan-serializer-8.0.0.jar
    The behavior we saw was weird to say the least. Basically, any process which utilized Mirth's native XML parsing and XSLT features was non functional. No errors were thrown in the server log, the mirth.log or anywhere. The message browser looked like channels simply had received or built empty payloads.

    The solution for us was to isolate the code which utilized the Docx4j resources away from everything else. In our case we had a specific channel which created an Excel workbook so we moved the code which required Docx4j objects into a single destination connector. We then configured the channel's dependencies to only include the Docx4j resource in the context for that single destination. This allowed the other parts of the channel which needed to work with XML objects (but not Docx4j XML objects) to continue using Mirth's classes and thus continue to function.

    The first warning we wanted to draw attention to in this post pertains to the context scope of custom resources. I believe it has already been a recommended best practice to isolate custom resources rather than just loading everything from custom-lib into the Default Resource, so that is nothing new. For us, we typically assign custom resources at the channel level, but in this case we we had to get more granular and narrow the context to a specific destination.

    The second word of warning pertains to potential consequence of the Default Resource's default settings. Depending on how you choose to implement your process for upgrading Mirth to a new version or how you restore a Mirth server, there are possible pitfalls. The Default Resource, by default, has the setting Include All Subdirectories checked although I don't believe the jars are loaded until you manually select Reload Resources in the UI (somebody feel free to correct me if this is inaccurate). The obvious defense against this risk when doing an upgrade or restoring from a backup is to just add a verification step; make sure your custom resources are still isolated, the Default Resource isn't including the subdirectories and reload resources as needed. The bigger risk IMO is when adding a custom resource: the act of dropping in your custom resource files under the custom-lib directory and reloading the Default Resource could potentially bring down any existing development which utilizes Mirth XML XSLT features.

    Ultimately, I don't know what changed in Mirth specifically but I suspect it had something to do with the class loading process. I don't know if it is a bug or not and I am not attempting to point fingers or lay blame. Rather, I was just very stumped for an embarrassingly long time and I am hoping this shortens somebody else's head-scratching period

  • #2
    TMarz
    OBX.2 Kenobi
    TMarz Good stuff there - you mind going over the Github and posting an issue? https://github.com/nextgenhealthcare/connect/issues. I don't work for Nextgen, just thinking you will get more visibility from them over there.
    Diridium Technologies, Inc.
    https://diridium.com

    Comment


    • #3
      Thanks! Good idea. I submitted the post : https://github.com/nextgenhealthcare...ct/issues/4947

      Comment

      Working...
      X