Mirth Connect
  1. Mirth Connect
  2. MIRTH-4198

Allow Resources to have child-first ClassLoader semantics

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Server
    • Labels:
      None

      Description

      Having a child-first ClassLoader for resources allows a channel, etc. to use library versions that are different from those provided by Mirth server or one of the extensions.

      As it stands, Mirth's provided libraries will take precedence over anything in any resource loader, so if Mirth bundles library X version 1 and the channel requires library X version 2, the channel will (likely) fail.

      Mirth should provide such child-first ClassLoaders to allow channels that require such semantics. This makes it much easier to deploy on Mirth without having to take the risky step of upgrading Mirth's provided libraries when a conflict exists.

        Activity

        Hide
        Jon Bartels added a comment -

        http://www.mirthcorp.com/community/issues/browse/MIRTH-3835 seems related. If I can get the isolated classloader does that imply that I can also easily set that classloader or set that classloader as the parent?

        Show
        Jon Bartels added a comment - http://www.mirthcorp.com/community/issues/browse/MIRTH-3835 seems related. If I can get the isolated classloader does that imply that I can also easily set that classloader or set that classloader as the parent?
        Hide
        Christopher Schultz added a comment -

        I was just bitten by this again. Because Mirth internally uses lots of popular libraries (e.g. Apache commons-lang3 in my case), it's not possible to require a higher-level version of a library without upgrading the version Mirth ships with, or there will be odd conflicts.

        Show
        Christopher Schultz added a comment - I was just bitten by this again. Because Mirth internally uses lots of popular libraries (e.g. Apache commons-lang3 in my case), it's not possible to require a higher-level version of a library without upgrading the version Mirth ships with, or there will be odd conflicts.
        Hide
        Jon Bartels added a comment -

        MC extensions can also contribute to this issue. I have a customer using a home grown library which depends on Apaches WSS4J which has a transitive dependency on OpenSAML 3.1.1. The commercial NextGen extension for XDS tools uses OpenSAML 2.6.4.

        If both the library and that NextGen extension are loaded, the library cannot run because of classpath conflicts. The workaround is to use the isolated classloader (see MIRTH-3835) to load the library and its dependencies. The isolated classloader works to solve this problem but it is a little challenging for channel engineers who are not also Java engineers to use.

        Is it possible or practical to define a channel that uses the isolated classloader by default and have that set as a checkbox option instead of having to do it manually in code?
        Does such an option to use the isolated classloader cover most of the use cases and reduce the need for a child-first loader?

        Show
        Jon Bartels added a comment - MC extensions can also contribute to this issue. I have a customer using a home grown library which depends on Apaches WSS4J which has a transitive dependency on OpenSAML 3.1.1. The commercial NextGen extension for XDS tools uses OpenSAML 2.6.4. If both the library and that NextGen extension are loaded, the library cannot run because of classpath conflicts. The workaround is to use the isolated classloader (see MIRTH-3835 ) to load the library and its dependencies. The isolated classloader works to solve this problem but it is a little challenging for channel engineers who are not also Java engineers to use. Is it possible or practical to define a channel that uses the isolated classloader by default and have that set as a checkbox option instead of having to do it manually in code? Does such an option to use the isolated classloader cover most of the use cases and reduce the need for a child-first loader?
        Hide
        Christopher Schultz added a comment -

        The isolated ClassLoader IMO is a step backward from a "parent-last" ClassLoader because it is more awkward to use.

        MC should use parent-last semantics by default for every channel (or, really, every resource-set) and that would solve 99% of these kinds of issues. The "isolated" ClassLoader should basically never be necessary. MC should isolate anything that the server needs to run itself from the resources required by various channels, unless MC is declaring that it provides specific libraries. Unfortunately, declaring that a library is provided (e.g. http-client) runs the risk that the server and the channel/resource-set disagree over which version is appropriate.

        It would therefore be best to isolate the server and let channels use whatever they want.

        Show
        Christopher Schultz added a comment - The isolated ClassLoader IMO is a step backward from a "parent-last" ClassLoader because it is more awkward to use. MC should use parent-last semantics by default for every channel (or, really, every resource-set) and that would solve 99% of these kinds of issues. The "isolated" ClassLoader should basically never be necessary. MC should isolate anything that the server needs to run itself from the resources required by various channels, unless MC is declaring that it provides specific libraries. Unfortunately, declaring that a library is provided (e.g. http-client) runs the risk that the server and the channel/resource-set disagree over which version is appropriate. It would therefore be best to isolate the server and let channels use whatever they want.

          People

          • Assignee:
            Unassigned
            Reporter:
            Christopher Schultz
          • Votes:
            7 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:

              Development